HDTenEightyP/NetNews huggingface dataset:
From: quan@mensa.surv.utas.edu.au (Stephen Quan)
Subject: Re: Can't build g++ on a DG.
Organization: University of Tasmania, Australia.
Date: Fri, 22 Jan 1993 01:54:16 GMT

quan@sol.surv.utas.edu.au (Stephen Quan) writes:

Hello, recently I've posted that I had problems in building GNU G++
on a Data General AViiON (DG 46/20 running OS 5.4.2).

I had our local guru have a look at it, and together we concluded
that gcc-2.2.2 compiles ok, but gcc-2.3.2 and gcc-2.3.3 do not
compile at all.

As indicated in my last post, the following errors occured whilst
building the initial GNU C compiler...


About 1000 assembler errors :

>as: "/var/tmp/cca003BA.s": line 24412: warning: instruction "fldcr" is
>inconsistent with -M 88000min
>as: "/var/tmp/cca003BA.s": line 24434: warning: instruction "fldcr" is
>inconsistent with -M 88000min


Stage 1 fails to build because the above step failed.

>UX:mv: ERROR: Cannot access stamp-proto: No such file or directory
>UX:mv: ERROR: Cannot access crtbegin.o: No such file or directory
>UX:mv: ERROR: Cannot access crtend.o: No such file or directory
>UX:mv: ERROR: Cannot access gcc-cross: No such file or directory
>UX:mv: ERROR: Cannot access cc1plus: No such file or directory
>UX:mv: ERROR: Cannot access cc1obj: No such file or directory
>UX:mv: ERROR: Cannot access protoize: No such file or directory
>UX:mv: ERROR: Cannot access unprotoize: No such file or directory
>UX:mv: ERROR: Cannot access collect2: No such file or directory
>*** Error code 2 (ignored)
>        rm -f stage1/libgcc.a
>        cp libgcc.a stage1
>        if [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ; then ranlib stage1/libgcc.a; else true; fi

Please help!!!
From: cpr4k@holmes.acc.Virginia.EDU (Christian P. Roberts)
Subject: Library Reference Manual
Organization: Academic Computing Center - U.Va.
Date: Thu, 21 Jan 1993 20:58:06 GMT

How can I obtain a copy of the G++ Library Reference Manual.
I untarred the file from prep.ai.mit.edu and found a file
named libg++.texinfo, from which you are supposed to be able
to get Emacs-type info files and TeX source from which to
get a hardcopy.  How do you get this texinfo file to split?

Please email.

-- 

Chris Roberts                     ITC/Academic Computing Center
cpr4k@virginia.edu                University of Virginia           
(804) 982-4693                    Charlottesville, Virginia 22903
Newsgroups: gnu.g++.help
From: jlieb@is.morgan.com (Jerry Liebelson)
Subject: Can gcc produce position-independent object code for shared libraries?
Keywords: gcc gnu shared -pic 
Organization: Morgan Stanley & Company, Inc.
Date: Tue, 26 Jan 1993 17:12:57 GMT

Or, what's the gcc equivalent of the cc -pic option for use with
compiling modules for subsequent linking into a SunOS 4.11 shared library?

Please answer from actual experience, thank you.

-- 
Jerry Liebelson
jlieb@is.morgan.com
Compuserve: 73477,2740
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: new operator with multiple arguments (gcc-2.2.2)
Date: 23 Jan 1993 00:55:17 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <22983@duke.cs.duke.edu> brinerj@mcduff.uncg.edu (Jack V. Briner Jr.) writes:
>I would like to pass arguments to the new operator (to select memory from
>different segments).  g++ does not seem to have this implemented under
>gcc-2.2.2.

Actually, it did, but used a different syntax.

The current version, gcc-2.3.3, supports the ARM (official) syntax and
compiles your program correctly.
--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.help
From: honglin@apmaths.uwo.ca (HONGLIN YE)
Subject: Re: Problem linking with g++ class
Organization: Applied Mathematics, U.W.O
Date: Tue, 26 Jan 1993 19:32:12 GMT

   
  Hi,

     I don't think you can get an answer from this news group for that 

  problen. There have been many help requests on that matter in the group,

  but people simply ignored or maybe they don't know the answer yet.







In article <1k3jc2INNjnk@iskut.ucs.ubc.ca> keith@msmri.med.ubc.ca writes:


>I am having difficulties linking to a very simple class with g++.
>The program compiles, links and runs properly with BC++ 3.1.  
>I am running gcc 2.3.3 
>with libg++ 2.3 on a SUN OS 4.1.1.  Gcc is installed in a directory
>other than /usr/local. 

>I have tried to make the class as simple as possible and based its 
>design on Complex.h in libg++.  I have tried a similiar test program
>with the Complex.h class and it compiled, linked and ran properly with
>g++.  The 2 test files and the class I am trying to link to are 
>included at the end of this file.

>When I type the command

>    g++ test1.c test2.c -lm

>I get the error message

>    ld: Undefined symbol 
>       ___7mpfloatRC7mpfloat 
>       ___7mpfloatd 
>       ___ml__FRC7mpfloatT0 
>       __$_7mpfloat 
>    collect: /usr/bin/ld returned 2 exit status

>I am obviously missing something simple.  Could someone please point
>it out to me.

>Thanks in advance.

>Keith S Cover
>Physics, UBC
>keith@msmri.med.ubc.ca

>test1.c
>=======

>#include <iostream.h>
>#include <math.h>
>#include "mpf14.h"

>mpfloat square(mpfloat a);

>main() {

>    mpfloat a = 4;
>    mpfloat b = square(a);

>    return 0;
>}


>test2.c
>=======

>#include "mpf14.h"

>mpfloat square(mpfloat a) {

>    return( a*a );

>}


>mpf14.h
>=======

>#ifndef _mpfloat_h
>#ifdef __GNUG__
>#pragma interface
>#endif
>#define _mpfloat_h 1


>// INCLUDE FILES 
>#include <iostream.h>
>#include <math.h>
>#include <stdlib.h>


>class mpfloat {

>protected:

>    double num;

>public:

>    // constructors and destructors
>    mpfloat();
>    mpfloat(const mpfloat& x);
>    mpfloat(const double x);
>    ~mpfloat();

>    // get value
>    double getnum() const;

>};


>// INLINE FUNCTION PROTOTYPES

>// Arithmetic operators
>mpfloat operator * ( const mpfloat& x, const mpfloat& y);

>// INLINE MEMBERS

>// constructors
>inline mpfloat::mpfloat() {
>}
>inline mpfloat::mpfloat(const mpfloat& x) :num(x.getnum()) {
>}
>inline mpfloat::mpfloat(const double x) {
>    num = x;
>}
>inline mpfloat::~mpfloat() {
>}


>// Get number
>inline double mpfloat::getnum() const {
>    return(num);
>}


>// Inline Functions

>inline mpfloat operator * ( const mpfloat& x, const mpfloat& y) {
>    return mpfloat( x.getnum()*y.getnum() );
>}

>#endif // _mpfloat_h
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: gnu.g++.help
Subject: Re: #pragma implementation
Date: 22 Jan 1993 20:33:57 GMT
Organization: U. C. Berkeley
Distribution: gnu
NNTP-Posting-Host: forney.berkeley.edu

In article <1993Jan22.060851.21068@athena.mit.edu> fritz@mtl.mit.edu (Frederick Herrmann) writes:
>The message:
>		 `#pragma implementation' can only appear at top-level
>
>is generated if the #pragma appears after a #line.  That makes sense
>most of the time, but is causing me some problems now because I want to
>put the pragma in the declaration section of bison deck.  Bison puts a
>#line control right at the top of the file.

You can avoid the problem by realizing that #pragma implementation
is not needed at all.  That is, if the file foo.C or foo.cc includes
foo.h, and foo.h has a #pragma interface, the effect is exactly the
same as if foo.C had a #pragma implementation, even though it does
not.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: gnu.g++.help
From: jas@dcs.warwick.ac.uk (Jason Morris)
Subject: What does this error mean?
Organization: Department of Computer Science, Warwick University, England
Date: Thu, 28 Jan 1993 18:24:58 GMT


  Simple enough question: in what circumstances would you expect to get this
message?

../include/vector.h:28: base class `Matrix<short int>' has incomplete type
../include/vector.h:28: please fix above error, and try recompiling.

  The line 28 bit seems to be fairly irrelevant (it's the closing "}" in the
declaration of type Vector<T>).

  Thanks for any advice,

    Jas.
From: brendan@cygnus.com (Brendan Kehoe)
Newsgroups: gnu.g++.lib.bug
Subject: [djb@babypuss.mitre.org : ]
Date: 26 Jan 1993 22:25:34 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: brendan@cygnus.com (Brendan Kehoe)

------- Start of forwarded message -------
From: djb@babypuss.mitre.org (David J. Braunegg)
To: bug-g++@prep.ai.mit.edu
Cc: djb@babypuss.mitre.org
Date: Fri, 22 Jan 93 17:29:04 -0500

This is a bug report for g++ (gcc) version 2.3.3, running on a Sun
Sparcstation, OS 4.1.


Your declaration of

        ostream& operator<<(void *p);

in iostream.h is in error.  Unless you have truly defined operator<<
on void* pointers so that it modifies the pointer, the declaration
should instead be

        ostream& operator<<(const void *p);



For example, the following program should *not* issue the const
violation warning that it does.



#include <iostream.h>

int main()
{
  const char *foo = "stuff";

  cout << (const void *)foo << endl;

  return 0;
}




djb@bambam>g++ -g -Wall test.cc
test.cc: In function `int  main ()':
test.cc:7: warning: argument passing of non-`const *' pointer from `const *'
test.cc:7: warning: argument passing of non-`const *' pointer from `const *'



I have encountered this warning frequently, because in my code I am
often writing out the address of an object to help identify it.  If
foo is `const <class> *', then I must cast it to `const void *' and
*not* to `void *' when printing its address in order to avoid a const
violation.


Please contact me if you have any further questions.

Dave

------- End of forwarded message -------

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Mountain View, CA                              +1 415 903 1400
                     ``In a cruel and imperfect world,'' says critic Rex Reed,
 ``[Audrey Hepburn] was living proof that God could still create perfection.''
From: bothner@cygnus.com
Newsgroups: gnu.g++.lib.bug
Subject: Re: 2.3: ios::showpos overeager on unsigneds
Date: 21 Jan 1993 18:21:34 -0500
Organization: GNUs Not Usenet
Distribution: gnu

> A careful reading of Stroustrup, "C++ prog lang", 2nd ed., page 340
> indicates that the showpos attribute of an ostream causes the printing
> of '+' signs for positive ints.

Do not count on Stroustrup to be accurate or complete when it comes
to the iostream library.

> With Sun C++, this program
> ======================================================================
> #include <iostream.h>
> 
> int main(int, char*[])
> {
>   unsigned u = 1;
>   cout.setf(ios::showpos);
>   cout << u << endl;
>   return 0;
> }
> ======================================================================
> prints
> 1
> as seems appropriate, since u is not a positive int.  With (patched)
> g++-2.3.3 and (patched) libg++-2.3, the same program prints
> +1

I disagee: 1 is a positive int.

However, my ANSI draft is unclear.  It says:

	If i is positive and showpos is on, decimal conversion converts
	it to a plus signed (+) followed by decimal digits.  The other
	conversions treat all values as unsigned.

It might *possibly* be interpreted to imply that unsigned conversion
should not show a '+'.  I don't think that is the most natural
interpretation, but I will ask for a clarification.

	--Per Bothner
Cygnus Support     bothner@cygnus.com
From: muenkel@tnt.uni-hannover.DE (Heiko Muenkel)
Newsgroups: gnu.g++.lib.bug
Subject: Error building libg++ 2.3
Date: 25 Jan 1993 21:01:53 -0500
Organization: Universitaet Hannover, Theoretische Nachrichtentechnik
Distribution: gnu
Reply-To: muenkel@tnt.uni-hannover.de

I'am trying to install the libg++ 2.3 with the gcc 2.3.3 on a Sparc 10 under
SunOS 4.1.3. While running make in the main-directory it seems that all things 
worked well. But while running make in the directory libg++-2.3/libg++/test-install
I get:

:
:
ld -e start -dc -dp -o foo_main.run /usr/lib/crt0.o -L/appl/gcc/Global/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.3 -L/appl/gcc/Global/lib -L/appl/gcc/Global/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.3 -L/appl/gcc/Global/lib -L/appl/gcc/Global/lib/gcc-lib/sparc-sun-sunos4.1.3/2.3.3 -L/appl/gcc/Global/lib foo_main.o foo_func.o Foo.o -lgcc -lc -lg -lgcc
/foo_main.run > foo_main.out
foo_main.cc:32: failed assertion `Foo::nb_foos() == 2'
sh: 2235 Abort - core dumped
*** Error code 134
make: Fatal error: Command failed for target `foo_main.out'


Could anybody help me ?


Thanks in advance,

Heiko
---
________________________________________________________________________________

Dipl.-Ing. Heiko Muenkel           Universitaet Hannover
				   Institut fuer Theoretische Nachrichtentechnik
				   und Informationsverarbeitung
muenkel@tnt.uni-hannover.de        Appelstrasse 9A
fax:    +49-511-762-5333           D-3000 Hannover 1
phone:  +49-511-762-5323           Germany
________________________________________________________________________________
From: bothner@cygnus.com
Newsgroups: gnu.g++.lib.bug
Subject: Re: Still stumped with libg++-2.3 under Ultrix 4.3
Date: 21 Jan 1993 18:22:26 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Most of these look like errors in libg++/_G_config.h.
Delete than file, and re-make it.  It should be consistent
with the system include files; otherwise tehre is a bug
in libg++/utils/gen-params.

	--Per Bothner
Cygnus Support     bothner@cygnus.com
From: howell/G=simon/S=guest/O=DEVELOPMENT@mhs.ATtmail.COM
Newsgroups: gnu.g++.lib.bug
Subject: libg++-2.2 problem (maybe bug?)
Date: 25 Jan 1993 21:01:31 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Hi,

I'm trying to build libg++-2.2 using gcc-2.2.2.

My machine is a Unisys/6035 running Unix SVR4.  I used configure i386-sysv4.

Everything proceeds fine until the make gets to libg++/src, and tries
to build AllocRing.cc.  At this stage, I get a this fatal error:

----------------------------------------------------------------------------
gcc -g -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
(EOF):undefined name: .L_B5_e
(EOF):undefined name: .L_B5
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)
----------------------------------------------------------------------------

Now, I'm not familiar with C++, but this rather looks like gcc is
having some problems compiling a C++ construct, which it handles using
some auto-generated name like L_B5_e or some such.

But the net result is that I can't build libg++-2.2.   I have no other
version of the library;  I need it so I can build groff-1.05.
Otherwise, I'm stuck.

So, is this a bug in libg++ or gcc, or what can I do about it?

If there's anything else you need to know about my environment, I'll
supply it on request.


Cheers,
Simon Guest.

PS: If I should have RTFM'd (which I tried), please tell me which M to R.
From: dougm@cs.rice.edu (Doug Moore)
Newsgroups: gnu.g++.lib.bug
Subject: 2.3: bogus failstate in getline
Date: 25 Jan 1993 20:27:44 -0500
Organization: GNUs Not Usenet
Distribution: gnu

As the following program indicates, when getline is called with a
buffersize of n and n-1 characters are put in the buffer, the state of
the istream is changed to fail.  This is inappropriate and contrary to
the behavior of Sun C++.  The line in igetline.C that brings this
about is easy to find and remove, but I hesitate.  It must be there
for some reason, right?

Program:
====================================================================
#include <iostream.h>

main()
{
  char buf[10];
  cin.getline(buf, sizeof(buf));
  cout << "Buffer is: " << buf << endl;
  cout << "cin state is " << cin.rdstate() << endl;
}
====================================================================
Output compiled with g++, libg++, input "abcdefghijklmnopqrstuvwxyz"
====================================================================
Buffer is: abcdefghi
cin state is 2
====================================================================
Output compiled with Sun C++, same input
====================================================================
Buffer is: abcdefghi
cin state is 0
====================================================================
Verbose compiler output:
====================================================================
g++ -o a.out -Wall -v bug.cc
Reading specs from /blossom/lib/gcc-lib/sun4/2.3.3/specs
gcc version 2.3.3
 /blossom/lib/gcc-lib/sun4/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 -Wall bug.cc /usr/tmp/cca27304.i
GNU CPP version 2.3.3 (sparc)
 /blossom/lib/gcc-lib/sun4/2.3.3/cc1plus /usr/tmp/cca27304.i -quiet -dumpbase bug.cc -Wall -version -o /usr/tmp/cca27304.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
 as -o /usr/tmp/cca273041.o /usr/tmp/cca27304.s
 /blossom/lib/gcc-lib/sun4/2.3.3/ld -e start -dc -dp -o a.out /lib/crt0.o -L/blossom/lib/gcc-lib/sun4/2.3.3 -L/blossom/lib /usr/tmp/cca273041.o -lg++ -lgcc -lc -lgcc
====================================================================

Both the compiler and library have been patched a bit.  The system is
sunos 4.1.2, on a sparc.

Doug Moore
(dougm@cs.rice.edu)
From: osyjm@cs.montana.edu (Jaye Mathisen)
Newsgroups: gnu.g++.lib.bug
Subject: Still stumped with libg++-2.3 under Ultrix 4.3
Date: 21 Jan 1993 18:00:34 -0500
Organization: CS
Distribution: gnu

OK, I made a virgin install of gcc-2.3.3, both with and w/o the 
install-fixincludes, and in either case, I get the following: (which is
different than what I was getting earlier...)  Decstation 5000/240, Ultrix
4.3.

Any help again appreciated, I have no idea where to go.  I've never
had trouble building the other libg++'s, but this one is giving me fits.

gcc -g -O -nostdinc++ -I.. -I. -I./../iostream -I./../g++-include  -c AllocRing.cc
In file included from ./std.h:26, from AllocRing.cc:22:
./../g++-include/string.h:28: declaration of `long unsigned int  strlen (const char *)'
<built-in>:0: conflicts with built-in declaration `unsigned int  strlen (const char *)'
In file included from ./std.h:28, from AllocRing.cc:22:
./../g++-include/unistd.h:92: conflicting types for `int  geteuid (...)'
/usr/include/unistd.h:219: previous declaration of `short int  geteuid (...)'
./../g++-include/unistd.h:93: conflicting types for `int  getegid (...)'
/usr/include/unistd.h:204: previous declaration of `short int  getegid (...)'
./../g++-include/unistd.h:94: conflicting types for `int  getgid (...)'
/usr/include/unistd.h:205: previous declaration of `short int  getgid (...)'
./../g++-include/unistd.h:102: conflicting types for `int  getuid (...)'
/usr/include/unistd.h:220: previous declaration of `short int  getuid (...)'
./../g++-include/unistd.h:143: conflicting types for `long int  lseek (...)'
/usr/include/unistd.h:208: previous declaration of `int  lseek (...)'
./../g++-include/unistd.h:144: conflicting types for `long int  read (...)'
/usr/include/unistd.h:172: previous declaration of `int  read (...)'
./../g++-include/unistd.h:145: conflicting types for `long int  write (...)'
/usr/include/unistd.h:180: previous declaration of `int  write (...)'
make[2]: *** [AllocRing.o] Error 1
make[1]: *** [in-src] Error 1
make: *** [all-libg++] Error 1

-- 
 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
From: bothner@cygnus.com
Newsgroups: gnu.g++.lib.bug
Subject: Re: 2.3: bogus failstate in getline
Date: 25 Jan 1993 21:26:21 -0500
Organization: GNUs Not Usenet
Distribution: gnu

> As the following program indicates, when getline is called with a
> buffersize of n and n-1 characters are put in the buffer, the state of
> the istream is changed to fail.  This is inappropriate and contrary to
> the behavior of Sun C++.

I'm following the ANSI draft (revision 4):

	Sets: failbit if it stops because it has extracted len-1 characters.

A comments says:
	Setting failbit in these circumstances is a change from the AT&T
	library, but seems sensible. ...

If you disagree, don't argue with me; argue with Jerry Schwarz (jss@lucid.com).

	--Per Bothner
Cygnus Support     bothner@cygnus.com
From: dougm@cs.rice.edu (Doug Moore)
Newsgroups: gnu.g++.lib.bug
Subject: 2.3: ostrstream and freeze
Date: 25 Jan 1993 20:49:24 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Unfreezing a previously frozen (with str) ostrstream, when that
ostrstream has a fixed, user-supplied buffer, causes the ostrstream
destructor to inappropriately delete the user-supplied buffer.

The program that follows should print, in an endless sequence,
"Hello!" and a memory address.  And with the Sun C++ implementation of
strstreams, it does.  With libg++, it crashes after the first
iteration.

Sun sparc.  Sunos 4.1.2.  g++ 2.3.3, with patches.  libg++ 2.3, with
patches.  Verbose compiler output:
======================================================================
g++ jnk.cc -o a.out -g -v -Wall
Reading specs from /blossom/lib/gcc-lib/sun4/2.3.3/specs
gcc version 2.3.3
 /blossom/lib/gcc-lib/sun4/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 -g -Wall jnk.cc /usr/tmp/cca07996.i
GNU CPP version 2.3.3 (sparc)
 /blossom/lib/gcc-lib/sun4/2.3.3/cc1plus /usr/tmp/cca07996.i -quiet -dumpbase jnk.cc -g -Wall -version -o /usr/tmp/cca07996.s
GNU C++ version 2.3.3 (sparc) compiled by GNU C version 2.3.3.
 as -o /usr/tmp/cca079961.o /usr/tmp/cca07996.s
 /blossom/lib/gcc-lib/sun4/2.3.3/ld -e start -dc -dp -o a.out /lib/crt0.o -L/blossom/lib/gcc-lib/sun4/2.3.3 -L/blossom/lib /usr/tmp/cca079961.o -lg++ -lgcc -lc -lg -lgcc

======================================================================

libg++ program output

======================================================================

0xf7fff6c8
Hello!
Segmentation fault

======================================================================

sun c++ program output (abbreviated)

======================================================================

Hello!
0xf7fff6dc
Hello!
0xf7fff6dc
Hello!
0xf7fff6dc

======================================================================

Program source:

======================================================================

#include <iostream.h>
#include <strstream.h>

int main(int, char*[])
{
  for(;;)
    {
      char buf[100];
      ostrstream strut(buf, sizeof(buf));
      strut << "Hello!" << ends;
      char *s = strut.str();
      cout << (void*)s << endl;
      cout << s << endl;
      strut.rdbuf()->freeze(0);
    }
  return 0;
}

======================================================================

Doug Moore
(dougm@cs.rice.edu)
From: mju@mudos.ann-arbor.mi.US (Marc Unangst)
Newsgroups: gnu.g++.lib.bug
Subject: Problems compiling libg++ v2.3 on i386 SVR4
Date: 25 Jan 1993 20:51:49 -0500
Organization: The Programmers' Pit Stop, Ann Arbor MI
Distribution: gnu

I'm trying to compile libg++ v2.3 on my Esix SVR4 system.  I'm using
gcc v2.3.3 as the compiler, configured for i386-sysv4.  libg++ is
configured for i386-sysv4 as well.  The only modifications I've made
to the default makefile were to add "CC=gcc", change "CC_FOR_BUILD" to
gcc, and add -O to CFLAGS.  Everything goes fine until it gets to
iomanip.C, at which point I get a

gcc: Internal compiler error: program cc1plus got fatal signal 6

error from gcc.  What's going on here?  Why is cc1plus getting
SIGABRT/SIGIOT?

-- 
Marc Unangst, N8VRH         | "Of course, in order to understand this you
mju@mudos.ann-arbor.mi.us   |  have to remember that the nucleus of the atom
                            |  is squishy."
                            |    -W. Scheider, from a Physics lecture