HDTenEightyP/NetNews huggingface dataset:
From: gml4410@ggr.co.UK (Lack Mr G M)
Subject: Bug in libg++-2.3 (using setfill/setw in iomanip).
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 17:22:29 GMT

     I  have  just  built  libg++-2.3  on both a Sun SparcStation (SunOS
4.1.1) and an SG Indigo (Irix 4.0.1) using gcc-2.3.3 and have discovered
what I think is a bug in the newly-added manipulators in iomanip.h. 

     To  test the setw/setfill I used trivial example from 3/4 down p348
of Stroustrup's "The C++ Programming Language" Second Edition  (this  is
in section 10.4.2.1).  Here is the entire code... 

==============================  Test Source  ===========================
#include <iostream.h>
#include <iomanip.h>

int main()
{
   cout << setw(4) << setfill('#') << '(' << 12 << ")\n";
   cout << '(' << 12 << ")\n";
   return 0;
}
============================  End Test Source  =========================

  The output expected is:

(##12)
(12)

     but I get

###(12)
(12)

     from which I infer that the setw(4) and setfill('#') are being used
for the output of '('.  In 10.4.1.2 Stroustrup that these specifications
should apply to the "next numeric or string" output operation.  '(' is a
char and so shouldn't be affected. 

NOTE:  AT&T's cfront 2.1 agrees with Stroustrup on this.  I checked...


-------------------------- Gordon Lack ----------------------------------
The contents of this message *may* reflect my personal opinion.  They are
*not* intended to reflect those of my employer, or anyone else.

To: info-gcc@prep.ai.mit.edu, info-g++@prep.ai.mit.edu
Cc: brendan@cygnus.com
Subject: g++ 2.3.3 and libg++: undefined symbols
Date: Mon, 04 Jan 93 15:06:46 -0800
From: brendan@cygnus.com
Distribution: world
Approved: info-gnu@prep.ai.mit.edu
Newsgroups: gnu.g++.lib.bug,gnu.g++.announce,gnu.gcc.announce
Followup-To: gnu.g++.lib.bug

The 2.3.3 release of gcc (g++) included a fix for how virtual table
names are mangled.  This creates an inconsistency between names the
compiler generates, and the names in any libg++ created with a
compiler before 2.3.3.  For example, one of the most common problems
people will face as a result of this change will be an error that the
symbol `__vt$10ostrstream$3ios' is undefined at link-time.

It is necessary to build a new libg++.a with the latest (2.3.3)
compiler to sync things back up.  This would probably also be a good
opportunity to upgrade to the libg++ 2.3 release if you haven't yet.

Thanks, and my apologies for any inconvenience this may cause.

Brendan Kehoe
Cygnus Support

Newsgroups: gnu.g++.lib.bug
From: bartm@cv.ruu.NL (Bart Muyzer)
Subject: libg++ 2.3 and gcc 2.3.3 on HP9k700; unsatisfied symbols??
Keywords: iostream
Organization: University of Utrecht, 3D Computer Vision Research Group
Distribution: gnu
Date: Thu, 7 Jan 1993 11:06:44 GMT

Hello,

As a followup to the patches for libg++ 2.2 on HP9000/700 systems, I'm
currently putting together a set of patches that makes a working libg++ 2.3 
with gcc 2.3.3 on  that kind of systems. I've managed to build the library and
to run nearly all the checks.

There's one problem I have been unable to  solve so far.
In the directory libg++/etc/fib, I get the following while running "make
check":

 gcc -O  -I./../../iostream -I./../../src -I./../.. -o fib fib.o ../../libg++.a
 ld: Unsatisfied symbols:
    __ls__FR7ostreamd (code)
    __ls__FR7ostreami (code)
    __ls__FR7ostreamPCc (code)
 collect: /bin/ld returned 1 exit status

Adding a little more verbosity uncovers:

 Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/specs
 gcc version 2.3.3
 /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/ld -u main -a archive -o fib /lib/crt0.o fib.o ../../libg++.a /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a -lc /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a
 ld: Unsatisfied symbols:
    __ls__FR7ostreamd (code)
    __ls__FR7ostreami (code)
    __ls__FR7ostreamPCc (code)
 collect: /bin/ld returned 1 exit status

It turns out that the "Unsatisfied symbols" aren't even in the just build
libg++.a!!????

When I link with version 2.2 of libg++, all works well. In libg++ 2.2, the
"Unsatisfied symbols" seem to come from the file 'iostream.o'.

Could anybody please help me ASAP? I want to post the patches the minute I
have things work to share them with other net-ters...

Thans very much in advance,
							>] Bartm [<

-- 
Bart Muyzer, Systems and Network Administrator, [NIC-Whois handle: BJM9]
     3D Computer Vision, Room E02.222, University Hospital Utrecht,
     Heidelberglaan 100, 3584 CX Utrecht, Holland. E-mail: bartm@cv.ruu.nl
     Fax: +31-30-513399. Tel: +31-30-506711 (w), +31-3402-52157 (h). 


Newsgroups: gnu.g++.lib.bug
From: bartm@cv.ruu.NL (Bart Muyzer)
Subject: HELP: libg++2.3/gcc 2.3.3 undefined symbols(HP9k700)
Keywords: undefined,iostream
Organization: University of Utrecht, 3D Computer Vision Research Group
Distribution: gnu
Date: Fri, 8 Jan 1993 08:39:03 GMT

Hello,

As a followup to the patches I posted a while ago which make libg++ 2.2 work
for HP9000/700 with gcc 2.3.1, I'm currently porting libg++ 2.3 to the
9000/700. I use gcc 2.3.3 fo this.

The port has been fairly easy so far, however one problem remains that I
haven't been able to solve yet:

While running "make check" in libg++/etc/fib I get:

  gcc -O  -I./../../iostream -I./../../src -I./../.. -o fib fib.o ../../li bg++.a
  ld: Unsatisfied symbols:
     __ls__FR7ostreamd (code)
     __ls__FR7ostreami (code)
     __ls__FR7ostreamPCc (code)
  collect: /bin/ld returned 1 exit status
*** Error code 1

Adding a little more verbosity, I get:

  gcc -v -O  -I./../../iostream -I./../../src -I./../.. -o fib fib.o ../../libg++.a
  Reading specs from /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/specs
  gcc version 2.3.3
   /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/ld -u main -a archive -o fib /lib/crt0.o fib.o ../../libg++.a /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a -lc /usr/local/lib/gcc-lib/hp700-hpux/2.3.3/libgcc.a
  ld: Unsatisfied symbols:
     __ls__FR7ostreamd (code)
     __ls__FR7ostreami (code)
     __ls__FR7ostreamPCc (code)
  collect: /bin/ld returned 1 exit status

Poking around in libg++ learned me that all of the symbols aren't even there!!

I compiled libg++ 2.3 with gcc 2.3.3 so it cannot be the "name mangling
problem" described by Brendan Kehoe (I guess).

The funny thing is that when I link with libg++ 2.2 (built with gcc 2.3.1),
all works well. In libg++ 2.2, the symbols seem to come from the "iostream.o"
module.

Could anybody please help me with this? I would like to post a new set of
patches ASAP to share my experiences...

Any help will be greatly appreciated!

							>] Bartm [<
-- 
Bart Muyzer, Systems and Network Administrator, [NIC-Whois handle: BJM9]
     3D Computer Vision, Room E02.222, University Hospital Utrecht,
     Heidelberglaan 100, 3584 CX Utrecht, Holland. E-mail: bartm@cv.ruu.nl
     Fax: +31-30-513399. Tel: +31-30-506711 (w), +31-3402-52157 (h). 


Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: libg++-2.3, IRIX 4.0.1, <math.h>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 14:48:50 GMT

> The SGI system headers define finite() to return int which conflicts
> with libg++ math.h double return value. I think this is just a typo in
> libg++ math.h. Shouldn't finite return int?

I agree.

> It would be nice if the libg++ math.h would include the system math.h

The plan is the libg++/g++-incldue will go away in favor of
auatmatically generated wrappers (except for old systems
without prototypes in the system headers).

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: jdc@.CSe.nau.EDU (John Campbell)
Subject: Problems with texinfo documentation in libg++2.3
Organization: Northern Arizona University, Flagstaff AZ
Distribution: gnu
Date: Thu, 7 Jan 1993 17:19:28 GMT

-- 
	John Campbell               John.Campbell@nau.edu
        jdc@sunset.cse.nau.edu      JDC@NAUVAX.UCC.NAU.EDU

Newsgroups: gnu.g++.lib.bug
From: BRAY@wcuvax1.wcu.edu (Jim Bray)
Subject: Internal compiler error while building libg++2.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 07:24:58 GMT

  Using gcc-2.3.3 and libg++-2.3, both configured as i486-sysv4:

  I pulled down a fresh copy of libg++-2.3 from prep in case my
previous problems were caused by bad sources.
I did "configure i486-sysv4".
I did "make clean."
I did "make all."
On my previous attempts (the last of which succeeded), I changed
CFLAGS from -g to -O2. I made no changes this time.
  The results:
gcc -g -O -nostdinc++ -I. -I.. -I. -I./../src -I./../g++-include -c
iomanip.C
gcc: Internal compiler error: program cc1plus got fatal signal 6
make[2]: *** [iomanip.o] Error 1
make[1]: *** [in-io] Error 1
make: *** [all-libg++] Error 1

  I will change CFLAGS to null and see what happens.

  I also unpacked the fresh copy on the i486-linux box, and got the
same "awk: syntax error
	source line number 2, file `needed2.awk'"
that I reported last night.


--Jim Bray (bray@wcuvax1.wcu.edu)

(Run Linux, the Official OS of the New World Order :))
(Please Support the League for Programming Freedom, and Boycott ATT
 because of their legal intimidation of BSDI, UCB, and CMU)

Newsgroups: gnu.g++.lib.bug,comp.unix.ultrix
From: osyjm@cs.montana.edu (Jaye Mathisen)
Subject: Compiling libg++-2.3 under ultrix 4.3, with gcc-2.3.3
Organization: CS
Date: Sun, 10 Jan 1993 20:14:04 GMT
Apparently-To: gnu-g++-lib-bug@uunet.uu.net
Distribution: world
Approved: info-gnu@prep.ai.mit.edu
Followup-To: gnu.g++.lib.bug,comp.unix.ultrix

Has anybody done this?  I have to make one change to the makefile that
generated _G_config.h to get the size_t stuff right, but now it's barfing
down in  Fix.cc with the following:

gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c Fix.cc
Fix.cc: In function `void  default_Fix_error_handler (const char *)':
Fix.cc:47: warning: implicit declaration of function `abort'
Fix.cc: In function `struct _Frep* _new_Fix (short unsigned int)':
Fix.cc:92: warning: implicit declaration of function `memset'
Fix.cc: In function `class Fix atoF (const char *, int (=  Fix_default_length ))':
Fix.cc:450: warning: implicit declaration of function `atof'
Fix.cc:450: cannot convert type `int '
Fix.cc:450:        to type `double &'


I had libg++-2.2 running, but building 2.3 has been a pain in the butt.
\

Any suggestions appreciated, my C++ skills are almost non-existent.
-- 
 Jaye Mathisen, COE Systems Manager                (406) 994-4780
 410 Roberts Hall,Dept. of Computer Science
 Montana State University,Bozeman MT 59717	osyjm@cs.montana.edu

Newsgroups: gnu.g++.lib.bug
From: lipp@sierra.COM (Damon Lipparelli)
Subject: finding installed libg++
Organization: Sierra Geophysics Inc.,  Kirkland, Wa
Distribution: gnu
Date: Tue, 12 Jan 1993 00:44:17 GMT

On an HP700 system, I've built libg++ 2.3 with gcc 2.3.3.  It gets
installed automatically into $(somedir)/lib/libg++.a (where $(somedir) is
determined by the configuration stage).  However, gcc doesn't look for
libg++.a by default and can't seem to find it if I specify it as -lg++ on
the command line.

I tried compiling the following program with "gcc -o tst tst.cc"
and gcc died with two or three unresolved symbol errors.  When I tried to
compile it with "gcc -o tst tst.cc -lg++", gcc said that it couldn't find
"-lg++".  This is all very strange since gcc doesn't have any trouble
finding the installed libg++ header files.

Is there something I'm missing?

Thanks for any information,
-lipp

ps:  Here is the test source.

// "tst.cc"
#include <iostream.h>

main()
{
  cerr << "here is some output" << endl;
}

--
Damon Lipparelli
Sierra Geophysics, Inc.
ARPA: lipp@sierra.com, UUNET: uunet!sgihbtn!lipp
Phone: (206) 822-5200 (x375)

Newsgroups: gnu.g++.lib.bug
From: marcello@deis20.cineca.it (Marcello Dalpasso)
Subject: infinity() declaration
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 18:57:11 GMT

The extern "C" declaration section in <math.h> should have

double infinity();

on my SunOS 4.1.1 SPARC

Bye

Newsgroups: gnu.g++.lib.bug
From: BRAY@wcuvax1.wcu.edu (Jim Bray)
Subject: Source filenames apparently affect symbol names
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 09:42:54 GMT

  The simple test program, partially included below, results in
multiply-defined symbols if compiled with the name "fstream.cxx", as
g++ fstream.cxx.
  It finally percolated thru my fossilized brainpan that the other
source of the mul-defs was libg++/iostream/fstream.o, and it occured
to me I should try compiling as
g++ foo.cxx
which compiles fine. The original fstream.cxx comes straight off of a
source disk of test/example programs from a c++ textbook, and is
believed to work with other c++ compilers. It was my belief that
source filenames were not significant in C, and the professor who is
teaching the c++ class believes that this should be the case in c++.
  The output of nm verifies this behavior. Compiled as foo.cc, the
only locally-defined symbol is main. Compiled as fstream.cc, what
appear to be member functions of libg++ classes are defined locally.
  I don't claim to know c++. Please be tolerant if this is a non-bug.

--Jim Bray (bray@wcuvax1.wcu.edu)

(Run Linux, the Official OS of the New World Order :))
(Please Support the League for Programming Freedom, and Boycott ATT
 because of their legal intimidation of BSDI, UCB, and CMU)



#include "fstream.h"
#include "stdlib.h"

void main()
{
ifstream infile;
ofstream outfile;
ofstream printer;
char filename[20];

   cout << "Enter the desired file to copy ----> ";

   cin >> filename;
   infile.open(filename, ios::nocreate);
   if (!infile) {
      cout << "Input file cannot be opened.\n";
      exit(1);

Newsgroups: gnu.g++.lib.bug
From: jbg@qualcomm.com (Jeff Gehlhaar)
Subject: Libg++ bug, version 2.3 (iostream)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 02:17:02 GMT

// In article <1992Dec29.170317.20721@dfv.rwth-aachen.de> of gnu.g++.lib.bug,
// Martin Junius <mj@dfv.rwth-aachen.DE> writes:
// >Just noticed a strange bug when redirecting libg++ 2.3 iostream 
// >output to a pipe: OUTPUT GETS LOST! This doesn't happen with 
// >normal output or redirection to a file.

// I have noticed the same behavior.  I have also noticed that after the
// initial line to cerr, output to cout also disappears.  However, in a
// strange exception, output from manipulators such as endl still occurs,
// resulting in a blank lines in the output.

// Martin's original example is not reproducible here, but this sample does
// show the problem in our environment.  (Jeff, please annotate this with
// our environmental specifics before forwarding it; it may be significant.)

// The result of ``g++ -v bug017.cc; a.out 2>&1 | cat; a.out'' is attached
// below.  The blank lines are part of the output.

// -- Greg

#include <iostream.h>

main()
{
        cerr << "Begin with line to cerr" << endl;
        cerr << "Another line to cerr" << endl;
        cout << "Try a line to cout" << endl;
        cout << "Try another line to cout" << endl;
}

/* ====================== output is below
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cpp -lang-c++ -v -undef
-D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__
-D__sun__ -D__unix__ -D__sparc -D__sun -D__unix bug017.cc
/usr/tmp/cca13773.i
GNU CPP version 2.3.3 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/cc1plus
/usr/tmp/cca13773.i -quiet -dumpbase bug017.cc -version -o
/usr/tmp/cca13773.s
GNU C++ version 2.3.3 (sparc) compiled by CC.
 as -o /usr/tmp/cca137731.o /usr/tmp/cca13773.s
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3/ld -e start -dc -dp
/lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.3
-L/usr/local/lib /usr/tmp/cca137731.o -lg++ -lgcc -lc -lgcc
Begin with line to cerr



Begin with line to cerr
Another line to cerr
Try a line to cout
Try another line to cout
========================= output is above */


======================================================
Jeff Gehlhaar           Qualcomm Inc,  
jbg@qualcomm.com        San Diego, CA, USA
(619) 597-5241          "The Elegant Solution...."
======================================================


Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: strstream bug?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 16:37:14 GMT

Please try the following:

===================================================================
RCS file: /rel/cvsfiles/devo/libg++/iostream/iostream.C,v
retrieving revision 1.32
diff -c -r1.32 iostream.C
*** 1.32	1992/10/17 00:26:36
--- iostream.C	1993/01/06 08:35:46
***************
*** 161,167 ****
  	    for (;;) {
  		ch = sb->sbumpc();
  		if (ch == EOF) {
! 		    set(ios::eofbit|ios::failbit);
  		    break;
  		}
  		else if (isspace(ch)) {
--- 161,167 ----
  	    for (;;) {
  		ch = sb->sbumpc();
  		if (ch == EOF) {
! 		    set(ios::eofbit);
  		    break;
  		}
  		else if (isspace(ch)) {

Newsgroups: gnu.g++.lib.bug
From: BRAY@wcuvax1.wcu.edu (Jim Bray)
Subject: (libg++2.3/g++2.3.3)Possible bug involving fstream.[Ch] (more)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 7 Jan 1993 16:36:04 GMT

  I think I forgot to mention that I was trying this with both
gcc-2.3.3 and libg++-2.3 configured for i486-sysv4.
  On my linux machine, I have installed hlu's gcc/g++/libg++/libc
images from tsx-11 (figuring less chance for me to screw things up,
and also when I attempted to make libg++ it quickly died with an awk
error) and attempted to compile the same file as in the previous
message. A whole slew of [87]*ifstream::... [87]*ofstream::..., and
fstreambase::... symbols are multiply-defined.
  The program involved is a c++ textbook example. It should be at
least sort of reasonable. 

--Jim Bray (bray@wcuvax1.wcu.edu)

(Run Linux, the Official OS of the New World Order :))
(Please Support the League for Programming Freedom, and Boycott ATT
 because of their legal intimidation of BSDI, UCB, and CMU)


Newsgroups: gnu.g++.lib.bug
From: BRAY@wcuvax1.wcu.edu (Jim Bray)
Subject: libg++-2.3 makes with -g removed from CFLAGS and CXXFLAGS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 8 Jan 1993 08:26:34 GMT

  Using gcc-2.3.3 and libg++-2.3, both configured as i486-sysv4:

  The "fatal signal six" error does not occur with CFLAGS and CXXFLAGS
of nil or -O2.
  I made and installed libg++ using no optimisation. 'make check'
still fails as in my previous note. The simple test program, the
beginning of which is included below, still fails as reported in my
previous message.

--Jim Bray (bray@wcuvax1.wcu.edu)

(Run Linux, the Official OS of the New World Order :))
(Please Support the League for Programming Freedom, and Boycott ATT
 because of their legal intimidation of BSDI, UCB, and CMU)

#include "fstream.h"
#include "stdlib.h"

void main()
{
ifstream infile;
ofstream outfile;
ofstream printer;
char filename[20];

   cout << "Enter the desired file to copy ----> ";

   cin >> filename;
   infile.open(filename, ios::nocreate);
   if (!infile) {
      cout << "Input file cannot be opened.\n";
      exit(1);

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Problems with libg++-2.3 compilation under SCO Open DeskTop 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 4 Jan 1993 15:41:35 GMT

I think you'll have to experiment until you find something that works.
If you do, and the changes are small and clean, I'll merge them in
(though kg++-include/curses.h may become obsolete soon).

I suggest you migght start with adding
	#undef lines
before the declaration of newline in g++-include/curses.h.
Also, look at the definition of _CURSES_FORMAT_ARG.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: apm@kikka.hut.fi (Antti Miettinen)
Subject: libg++-2.3, IRIX 4.0.1, <math.h>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 5 Jan 1993 06:45:08 GMT

Three minor things about libg++ math.h header file.

In libg++ math.h header there is a test for certain systems for which
inline isinf() and isnan() functions are defined. I think sgi should
be included in the test. SGI math library doesn't have isnan() or
isinf() (or I can't just find them). Seems that in libg++ only dtoa()
uses them and it is commented as obsolete so this may not be very
important.

The SGI system headers define finite() to return int which conflicts
with libg++ math.h double return value. I think this is just a typo in
libg++ math.h. Shouldn't finite return int?

It would be nice if the libg++ math.h would include the system math.h
so one could use functions defined there (like sinf(), cosf() etc)
without hardcoding /usr/include to #include or explicitly declaring
the protos.



Newsgroups: gnu.g++.lib.bug
From: steve@jack.sns.COM (J. Steven Harrison)
Subject: SCO 386 Build of libg++-2.3
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 3 Jan 1993 11:44:28 GMT

All,

I am trying to build libg++-2.3 on a Intel 486 box running SCO UNIX 3.2v4

This is config.status
--------------------------------------------------
#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
./configure i386-sco3.2v4 --prefix=/usr/local -norecursion 
# using "config/mh-sco"
--------------------------------------------------


Here is the output from early in the build.
--------------------------------------------------

insque.c
        cc -c -g -I. -I./../include   bcmp.c
bcmp.c
        cc -c -g -I. -I./../include   rindex.c
rindex.c
        cc -c -g -I. -I./../include   random.c
random.c
        rm -rf libiberty.a
        ar qc libiberty.a \
	argv.o basename.o concat.o cplus-dem.o fdmatch.o  getopt.o getopt1.o o
	bstack.o spaces.o strerror.o strsignal.o bcopy.o vfork.o getpagesize.o alloca.o
	sigsetmask.o index.o bzero.o insque.o bcmp.o index.o rindex.o random.o
        true libiberty.a
Make: Couldn't load Shell.  Stop.
*** Error code 1

Stop.
--------------------------------------------------

Am I doing something wrong or do I need a fix for this?

I had no troubles (one small one) on my Sun4 but this looks rather strange!


-- 
J. Steven Harrison, PhD.	steve@jack.sns.com
45034 Imnaha Court		Voice:	(510)623-8651
Fremont, CA   94539-6669	Data:	(510)623-8652
Systems'n'Software            	FAX:	(510)623-8656 


Newsgroups: gnu.g++.lib.bug
From: jdc@.CSe.nau.EDU (John Campbell)
Subject: Problems with texinfo documents in libg++2.3 (2nd try)
Organization: Northern Arizona University, Flagstaff AZ
Distribution: gnu
Date: Sat, 9 Jan 1993 04:05:37 GMT

(Funny, My last attempt had no text in the news article body.  Hmm.)

Problems with texinfo documentation in libg++2.3

I ran across the following problems making postscript files using
tex (and texinfo) in the libg++2.3 package.

1) The file gperf.texinfo didn't seem to like texinfo version 2.89.
   I was able to get a good dvi file using texinfo version 2.1.

2) iostream.texi had errors where iostream& was used in a deftypefn.
   I changed it to iostream@& and that seemed to fix the problem.
   I found three places where & needed to be escaped.

   An example:

 @deftypefn Method ostream& ostream::vform(const char *@var{format}, ...)

   became:

 @deftypefn Method ostream@& ostream::vform(const char *@var{format}, ...)

3) The cygnus etc/{intro,relnotes}.texi files used fonts that
   are not common in standard tex.  I was wondering if someone
   could recommend a substitution list for these (since they
   seem sort of generic):

   \texttt=pcrr         \textbf=pncb            \textit=pncri
   \textsl=pcrro        \textsf=slcrst          \ftfnt=phvr
   \indrm=pcnr          \chapit=pncbi           \chapsl=pcrbo

By the way, I appreciate the work that Cygnus has been doing.  It's
a lot easier to bring up new Gnu versions these days!
-- 
	John Campbell               John.Campbell@nau.edu
        jdc@sunset.cse.nau.edu      JDC@NAUVAX.UCC.NAU.EDU

Newsgroups: gnu.g++.lib.bug