HDTenEightyP/NetNews huggingface dataset:
From: dougm@cs.rice.edu (Doug Moore)
Subject: sign bug in stream.C: itoa
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 03:16:35 GMT

(previous posted inadvertantly to bug-g++)

The use of the itoa function in stream.C, as via dec(), places the minus
sign for negative numbers after the number, rather than before it.
The following patch fixes the problem.

Doug Moore (dougm@cs.rice.edu)


*** stream.C~	Mon Apr 13 21:08:54 1992
--- stream.C	Mon Apr 13 21:18:20 1992
***************
*** 44,51 ****
      if (needed < (2+neg) || ptr > EndBuffer)
  	return NULL;
      *--ptr = 0;
-     if (neg)
- 	*--ptr = '-';
      
      if (i == 0)
  	*--ptr = '0';
--- 44,49 ----
***************
*** 58,63 ****
--- 56,63 ----
  	    ch += '0';
  	*--ptr = ch;
      }
+     if (neg)
+ 	*--ptr = '-';
      if (size == 0)
  	return ptr;
      while (ptr > buf)




Newsgroups: gnu.g++.lib.bug
From: steve@lia.COM (Stephen Williams)
Subject: libg++ 2.0 or AIX 3.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 9 Apr 1992 06:57:59 GMT

I'm trying to compile libg++ on an RS/6000 running AIX 3.2.
I have managed to compile gcc 2.1, and applied the AIX 3.1
version of the assembler fix.  (Seems to work.) However I
get the following when trying to compile regex.cc. Is there
something silly that I did here?

Thanks in advance.
Steve Williams
steve@lia.com

gcc -I. -I./../iostream -I./../g++-include  -c regex.cc
In file included from regex.cc:124:
./../g++-include/regex.h:35: warning: `RE_DUP_MAX' redefined
/usr/include/sys/limits.h:103: warning: this is the location of the
previous def
inition
Assembler:
/tmp/ccMV8DFW.s: line 2704: undefined symbol ".isalpha__Fc"
/tmp/ccMV8DFW.s: line 2704: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2720: undefined symbol ".isupper__Fc"
/tmp/ccMV8DFW.s: line 2720: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2736: undefined symbol ".islower__Fc"
/tmp/ccMV8DFW.s: line 2736: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2752: undefined symbol ".isdigit__Fc"
/tmp/ccMV8DFW.s: line 2752: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2768: undefined symbol ".isalnum__Fc"
/tmp/ccMV8DFW.s: line 2768: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2784: undefined symbol ".isxdigit__Fc"
/tmp/ccMV8DFW.s: line 2784: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2800: undefined symbol ".isspace__Fc"
/tmp/ccMV8DFW.s: line 2800: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2816: undefined symbol ".isprint__Fc"
/tmp/ccMV8DFW.s: line 2816: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2832: undefined symbol ".ispunct__Fc"
/tmp/ccMV8DFW.s: line 2832: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2848: undefined symbol ".isprint__Fc"
/tmp/ccMV8DFW.s: line 2848: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2854: undefined symbol ".isspace__Fc"
/tmp/ccMV8DFW.s: line 2854: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 2870: undefined symbol ".iscntrl__Fc"
/tmp/ccMV8DFW.s: line 2870: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 4035: undefined symbol ".isdigit__Fc"
/tmp/ccMV8DFW.s: line 4035: illegal expression type for branch address
/tmp/ccMV8DFW.s: line 4114: undefined symbol ".isdigit__Fc"
/tmp/ccMV8DFW.s: line 4114: illegal expression type for branch address
The error code from the last failed command is 1.

Make Quitting.
The error code from the last failed command is 2.

Make Quitting.
Elapsed=0:24  CPU=91%(sys=1.7, user=21.17) Memory=1356

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: ctype.h problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 5 Apr 1992 15:49:45 GMT

sjg@melb.bull.oz.au (Simon J Gerraty) writes:
>One suggestion was:
>#include_next <ctype.h>
...
>On other machines such as the sun386, the system's ctype.h is
>not ANSI compatible (toupper,tolower are macros with side
>effects) and cannot be used.

It follows that such a ctype.h cannot be used for C programs.
Why should I add to my maintainance problems in order to
make ANSI *C* header files work better for g++ than for gcc?

>Please don't do this.

Sorry.  I suggest you fix the C header files (copy the fixed version
where gcc fixincludes installs things) - or get a new C library.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: behe@inasys.UUCP (Bernd Hentig)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 20:28:07 GMT

Hello,

I just installed GCC 2.1 (gcc, g++) and compared stage1 with stage2 -> OK.
(configure i386-isc)                             
The c compiler seems to work fine -> test progs o.k., even with -posix tests.
The building of the libg++2.0 (configure i386-isc-sysv32) succeeded in making
the 'src' subdir, but failed on iostream (Version 0.7) with the following
output:


	(rootme=`pwd` ; export rootme ; cd iostream ; \
		make "CC=`if [ -d ${rootme}/../gcc ] ; \
	then echo ${rootme}/../gcc/gcc -B${rootme}/../gcc/ ; \
	else echo /usr/local/bin/gcc ; fi`" "XTRAFLAGS=`if [ -d ${rootme}/../gcc ] ; \
	then echo -I${rootme}/../gcc/include ; \
	else echo ; fi`" \
		"AR=ar" "RANLIB=echo")
	/usr/local/bin/gcc -I. -I./../g++-include  -c stdstrbufs.C
Assembler: stdstrbufs.C
	aline 17	: syntax error
	aline 35	: syntax error
	aline 53	: syntax error
	aline 71	: syntax error
*** Error code 1

Stop.
*** Error code 1

Stop.

I remembered to have had this problem with gcc-1.40/g++1.40 when I forgot 
to define -DFASCIST_ASSEMBLER to tell gcc that I'm not using gas
(I'm NOT using any GNU tools except gcc/g++).

So I recompiled gcc with -DFASCIST_ASSEMBLER on, but got the same results
with libg++.

I'm not an expert at gnu software or compiler building, but I think this
must be a specific problem with my site configuration and I don't want to
blame me when posting any news :)
SO PLEASE, if you know what I've done wrong (I already tried out various
configuration with i386*), send me a short note !

I am on a UUCP (inasys.uucp) site connected to the German UseNet 
Backbone (unido), which you may reach via uunet or mcsun, but I 
think our domain is already in some mapping tables in the U.S.

Thanks very much for any help
Bernd Hentig

behe@inasys.uucp
...!mcsun!unido!inasys.uucp!behe


%



Newsgroups: gnu.g++.lib.bug
From: jmessenger@cix.CLink.co.UK (John Messenger)
Subject: Correction to libg++2.0 String: :OK
Reply-To: jmessenger@cix.clink.co.uk
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 1 Apr 1992 18:00:00 GMT

This is the OK function from the String class in libg++2.0.  If you
haven't got GNU ld, this is where you end up with a core dump because
rep (zero) is dereferenced.  Might I suggest this mod to String::OK
and similar functions to protect against dereferencing NULL pointers
and also beg for a suitable comment in the libg++ README and .texinfo
files telling you that you need support in the linker for
initialisation of constructors (such as is provided by GNU ld and not
provided by for example SunOS ld).
        -- John Messenger.
PS Please reply as I'm not sure if my mail makes it.
------------ Context diff follows ----------------------------
*** String.cc-dist	Wed Apr  1 14:47:22 1992
--- String.cc	Wed Apr  1 14:49:55 1992
***************
*** 1305,1313 ****
  
  int String::OK() const
  {
!   int v = rep != 0;             // have a rep
!   v &= rep->len <= rep->sz;     // string within bounds
!   v &= rep->s[rep->len] == 0;   // null-terminated
    if (!v) error("invariant failure");
    return v;
  }
--- 1305,1313 ----
  
  int String::OK() const
  {
!   int v = rep != 0;               // have a rep
!   v = v && rep->len <= rep->sz;   // string within bounds
!   v = v && rep->s[rep->len] == 0; // null-terminated
    if (!v) error("invariant failure");
    return v;
  }

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: g++-include/stdio.h bug and fix on Sequent Symmetry
Organization: Harvey Mudd College
Distribution: gnu
Date: Sat, 28 Mar 1992 20:40:59 GMT

The stdio.h that comes with libg++ 2.0 insists that any machine based on
the intel 386 is a USG machine, which the Symmetry is not.  So:

*** /staff/jason/.autosave/!gnu!libg++-2.0!libg++!g++-include!stdio.h~  Thu Mar
26 10:05:23 1992
--- g++-include/stdio.h Fri Mar 27 18:00:28 1992
***************
*** 77,83
  #define SPRINTF_RETURNS_INT
  #define USG

  #elif defined(TEKTRONIX_SYSV) || defined(hp9000s300) || defined(i386)
  #define  USG
  #endif


--- 77,85 -----
  #define SPRINTF_RETURNS_INT
  #define USG

+ #elif defined(sequent)
+
  #elif defined(TEKTRONIX_SYSV) || defined(hp9000s300) || defined(i386)
  #define  USG
  #endif

--
Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: iostream missing operator>>(istream&,streambuf*)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 08:49:57 GMT

>OK, now how about istream& get(streambuf&, char = '\n')?

Hmph! Some people are never satisfied!

	--Per Bothner
Cygnus Support     bothner@cygnus.com

igetsb.C:
//    This is part of the iostream library, providing input/output for C++.
//    Copyright (C) 1992 Per Bothner.
//
//    This library is free software; you can redistribute it and/or
//    modify it under the terms of the GNU Library General Public
//    License as published by the Free Software Foundation; either
//    version 2 of the License, or (at your option) any later version.
//
//    This library is distributed in the hope that it will be useful,
//    but WITHOUT ANY WARRANTY; without even the implied warranty of
//    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
//    Library General Public License for more details.
//
//    You should have received a copy of the GNU Library General Public
//    License along with this library; if not, write to the Free
//    Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

#include "ioprivate.h"
#include "iostream.h"

istream& istream::get(streambuf& sb, char delim /* = '\n' */)
{
    _gcount = 0;
    if (ipfx1()) {
	register streambuf* isb = rdbuf();
	for (;;) {
	    int len = isb->egptr() - isb->gptr();
	    if (len <= 0)
		if (isb->underflow() == EOF)
		    break;
		else
		    len = isb->egptr() - isb->gptr();
	    char *delimp = (char*)memchr((void*)isb->gptr(), delim, len);
	    if (delimp != NULL)
		len = delimp - isb->gptr();
	    int written = sb.sputn(isb->gptr(), len);
	    isb->gbump(written);
	    _gcount += written;
	    if (written != len) {
		set(ios::failbit);
		break;
	    }
	    if (delimp != NULL)
		break;
	}
    }
    return *this;
}

Newsgroups: gnu.g++.lib.bug
From: burton@heurikon.UUCP (Kevin Burton)
Subject: libg++ link problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 17:25:16 GMT

OS: m68k System Vr3 Unix
Compiler: gcc-2.1
Version: libg++-2.0

I have succesfully compiled and linked gcc/g++ 2.1 on our system. The next
step was to build libg++. There was some descrepancy between the stdio.h
int g++-include and the one in the compilers directory so I changed that
and libg++ compiled successfully. When I try to do "make check" I get
the following output:

gcc  -DLO_CAL -I. -I./../../iostream -I./../../g++-include -v -DUSG -c version.cc 
Reading specs from /usr/local/lib/gcc-lib/hkv/2.1/specs 
gcc version 2.1 
 /usr/local/lib/gcc-lib/hkv/2.1/cpp -lang-c++ -v -DLO_CAL -DUSG -I. -I./../../iostream -I./../../g++-include -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dmc68000 -Dmc68k -Dm68k -Dunix -D__mc68000__ -D__mc68k__ -D__m68k__ -D__unix__ -D__mc68000 -D__mc68k -D__m68k -D__unix -D__HAVE_68881__ -Dmc68020 version.cc /usr/tmp/cca09579.i 
GNU CPP version 2.1 (68k, MIT syntax) 
 /usr/local/lib/gcc-lib/hkv/2.1/cc1plus /usr/tmp/cca09579.i -quiet -dumpbase version.cc -version -o /usr/tmp/cca09579.s 
GNU C++ version 2.1 (68k, MIT syntax) compiled by GNU C version 2.1. 
 /usr/local/lib/gcc-lib/hkv/2.1/as -mc68020 -o version.o /usr/tmp/cca09579.s 
gcc -o gperf new.o options.o iterator.o main.o gen-perf.o key-list.o list-node.o hash-table.o bool-array.o read-line.o std-err.o version.o  ../../libg++.a 
Reading specs from /usr/local/lib/gcc-lib/hkv/2.1/specs 
gcc version 2.1 
 /usr/local/lib/gcc-lib/hkv/2.1/ld -o gperf /lib/crt0.o -L/usr/local/lib/gcc-lib/hkv/2.1/ -L/usr/local/lib/ new.o options.o iterator.o main.o gen-perf.o key-list.o list-node.o hash-table.o bool-array.o read-line.o std-err.o version.o ../../libg++.a -lgcc -lc -lgcc 
undefined                       first referenced 
 symbol                             in file 
libgxx_bcopy__FPCvPvUl              ../../libg++.a 
ld fatal: Symbol referencing errors. No output written to gperf 
collect: /bin/ld returned 13 exit status 

I am assuming that the mangled name with "bcopy" is due to some BSD/SYSV
difference in memory routines but I don't know where to go to fix it. As
you see I have compiled with -DUSG. Do I need another flag for SYSV ?
Any help would be appreciated.

Thanks.


Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: iostream missing operator>>(istream&,streambuf*)
Organization: Harvey Mudd College
Distribution: gnu
Date: Sun, 12 Apr 1992 07:26:20 GMT

I'm not sure exactly what this is supposed to do, but the Borland C++
iostream implementation includes it, and the NIHCL 3.0 expects it to be
there.

--
Jason Merrill
jason@jarthur.claremont.edu



Newsgroups: gnu.g++.lib.bug
From: axel@thor.informatik.uni-osnabrueck.de (Axel Schreiner)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 11 Apr 1992 09:33:17 GMT

For NeXT 2.1 the following patch fixes libg++-2.0/libg++/g++-include/time.h
so that /usr/include/time.h is, in fact, included. The original code
contains #ifndef __NeXT__ .. #else #ifndef __NeXT__ .. #endif #endif,
which does not make sense to me.
This patch is required to compile groff-1.05 with gcc-2.1 on the NeXT.

*** time.h-orig	Fri Apr 10 17:28:06 1992
--- time.h	Fri Apr 10 17:28:28 1992
***************
*** 46,58 ****
  #define _INCLUDE_POSIX_SOURCE
  #endif
  
- #ifndef __NeXT__
  #include_next <time.h>
- #else
- #ifndef __NeXT__
- #include "//usr/include/time.h"
- #endif
- #endif
  #endif
  #undef __time_h_recursive
  
--- 46,52 ----


Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: libg++ and strtol
Organization: Harvey Mudd College
Distribution: gnu
Date: Tue, 7 Apr 1992 23:18:46 GMT

bothner@cygnus.com writes:

>strtol is required by ANSI.

4.2bsd never claimed to be ANSI

>>The Sequent version of Unix (bsd 4.3ish) does nor provide it

Actually, Dynix is more 4.2ish than 4.3ish.  As far as I know, it supports
all 4.2isms, but not all 4.3isms (such as, say, strtol).

>>I am not using it so why is it required.

>Becase it is used for I/O.

Why can't you use the stroul function included with iostream in its place?
strtoul checks for unary minus and all, so it should return the correct
value.  The only problem spot would be, I suppose, in overflow conditions,
when strtoul returns ULONG_MAX, which evaluates to -1 in a 2's complement
representation.

Jason Merrill
jason@jarthur.claremont.edu

Newsgroups: gnu.g++.lib.bug
From: dougm@cs.rice.edu (Doug Moore)
Subject: new.cc does not include new.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 03:03:47 GMT

(inadvertantly mailed to bug-g++ previously)

In fact, no libg++ source file includes new.h, so that, with #pragma
interface being the way it is, sometimes a program that uses alternate
placement syntax for new fails to link.

Dougm

Newsgroups: gnu.g++.lib.bug
From: purtill%idacrd@uunet.uu.net (Mark Purtill)
Subject: #pragma interface -- whose bug is it anyway?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 14:48:44 GMT

	Okay, I figured out what was going wrong.  I had to rename the
int.SplayNode.C file to int.SN.C as it has to placed in a CRAY archive
with a 14 character limit.  This messes up the interface/implementation
stuff. (E.g., if you create a file "C.C" containing:
	#include "A.h"
	#pragma implementation
and link together with my previous "B.C", you'll get A::A() undefined.)
	Sorry for bothering the list with a non-bug, but if those
pragmas had been documented, you wouldn't have been bothered.

^.-.^ Mark Purtill, IDA/CCR-P, Thanet Road, Princeton NJ  08540; (609)924-4600.
((")) Email: purtill%idacrd@princeton.edu; uunet!idacrd!purtill. (609)497-0526.

Newsgroups: gnu.g++.lib.bug
From: lee@wang.COM (Lee Story)
Subject: Re: libg++ link problem
Organization: Wang Laboratories, Inc.
Distribution: gnu
Date: Tue, 14 Apr 1992 15:10:03 GMT

(I can't seem to find a mail address for libg++ bugs, so am posting to
the group, cc: bothner@cygnus.com.}

In article <9204072025.AA18648@rtl.cygnus.com> bothner@cygnus.com writes:
   >undefined                       first referenced
   > symbol                             in file
   >libgxx_bcopy__FPCvPvUl              ../../libg++.a

   Fix the parameter list in src/bcopy.cc to match g++-include/memory.h.

Yes.  The SCO Unix V3.2v2 build has the same problem and the same fix.

Various "SYSV" and "USG" definitions don't get propagated through the
makefiles for the SCO build---I  had to edit them in by hand after
configuring from the cygnus-supplied top level with
  "configure i386-ibm-sco".

libg++.texinfo doesn't format properly with the texinfo-format-buffer
command in emacs 18.55 or 18.57.

Also, I found these problems in the new iostream code while building
for SCO Unix (my fixes were crude, so I won't supply specific diffs):

In ioconfig.h:

#undef NAMES_HAVE_UNDERSCORE
 /* must NOT be defined for SCO */

#define NO_DOLLAR_IN_LABEL
 /* needed for SCO */

In makebuf.C:

#define NO_ST_BLKSIZE 1
 /* needed for SCO */

 /* next two reversed---stat.h needs file.h in SCO Unix */
#include <sys/file.h>
#include <sys/stat.h>
--
------------------------------------------------------------------------
  Lee Story (lee@wang.com) Wang Laboratories, Inc.
              (Merrimack Valley Paddlers)
------------------------------------------------------------------------

Newsgroups: gnu.g++.lib.bug
From: Ron.Sommeling@cwi.NL (Ron Sommeling)
Subject: Rational class
Organization: CWI, Amsterdam
Distribution: gnu
Date: Wed, 15 Apr 1992 07:48:12 GMT

There seems to be a bug in the Rational class of libg++ 2.0.
The following program is compiled with g++ 2.1 on a SPARCstation 1 running
SunOS 4.1.1

Ron Sommeling <Ron.Sommeling@cwi.nl>

% cat t.cc  
#include <iostream.h>
#include <Rational.h>

main() {
  cout << Rational(2,3) << endl;
}
% g++ -v t.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/specs
gcc version 2.1
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/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 t.cc /usr/tmp/cca02232.i
GNU CPP version 2.1 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/cc1plus /usr/tmp/cca02232.i -quiet -dumpbase t.cc -version -o /usr/tmp/cca02232.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o t.o /usr/tmp/cca02232.s
 ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.1/ -L/usr/local/lib/ t.o -lg++ -lgcc -lc -lgcc
% ./a.out
Segmentation fault

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: iostream missing operator>>(istream&,streambuf*)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 05:12:30 GMT

Try the following:

istream& operator>>(istream& is, register streambuf* sbuf)
{
    if (is.ipfx0()) {
	register streambuf* inbuf = is.rdbuf();
	// FIXME: Should optimize!
	for (;;) {
	    register int ch = inbuf->sbumpc();
	    if (ch == EOF) {
		is.set(ios::eofbit);
		break;
	    }
	    if (sbuf->sputc(ch) == EOF) {
		is.set(ios::failbit);
		break;
	    }
	}
    }
    return is;
}

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: Failed test-install in libg++-2.0 if compiled with gcc-2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 10:55:57 GMT

>Does this mean that gcc and NIHCL are and will remain incomapable??

NIHCL should be re-written to not depend on being able to
"run something after the initializers but before main()".  This is
not supported by AT&T's compiler either; my understanding is that
NIHCL uses some non-portable kludge.  My impressions is that
Gorlen has agreed that NIHCL could and should be fixed to not
need this kludge; I don't know any specifics.

To summarize: the bug is/was in NIHCL, not gcc; the fix should
be there as well.

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: freeman@devon.prepnet.com (Jon Freeman)
Subject: Problem installing libg++ version 2.0
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 15 Apr 1992 14:14:33 GMT

I built libg++ version 2.0 on a Sun Sparc 1+ with gcc version 2.0.
It seems to build fine, but here's what happens when I test it:

ben /home/local/gnu/libg++-2.0/libg++/test-install [ 625 ] make
/usr/local/bin/gcc -c foo_main.cc
/usr/local/bin/gcc -c foo_func.cc
/usr/local/bin/gcc -c Foo.cc
/usr/local/bin/gcc -g -v -o foo_main.run  foo_main.o foo_func.o Foo.o
Reading specs from /usr3/local/lib/gcc/sparc-sun-sunos4.1/2.0/specs
gcc version 2.0
 ld -e start -dc -dp -o foo_main.run /lib/crt0.o -L/usr3/local/lib/gcc/sparc-sun
-sunos4.1/2.0/ -L/usr3/local/lib/gcc/ -L/usr3/local/lib/ foo_main.o foo_func.o F
oo.o -lgcc -lc -lg -lgcc
./foo_main.run > foo_main.out
foo_main.cc:32: failed assertion `Foo::nb_foos() == 2'
sh: 7009 Abort - core dumped
*** Error code 134
make: Fatal error: Command failed for target `foo_main.out'
ben /home/local/gnu/libg++-2.0/libg++/test-install [ 626 ]

What's going on?  Is this something I should worry about?

				Thanks,
				 Jon
				 (freeman@devon.prepnet.com)

Newsgroups: gnu.g++.lib.bug