tale@cs.rpi.edu (David C Lawrence) (12/17/89)
[The original was just on the bug-g++ list; the bug I am posting about seems to be more with libg++.] In article <1069*metz@iam.unibe.ch> metz@iam.unibe.ch (Igor Metz) writes: > Configuration: > Sun-4 SunOS 4.0.3 > g++ 1.36.2 from interviews.stanford.edu > libg++ 1.36.1 from prep.ai.mit.edu I have the same configuration. I also just compiled g++ for our Sun3s, OS 3.5, nfp. > Problems: > 1) g++ version 1.36.2 (based on GCC 1.36) gets fatal signal 6 and dumps core > when compiling src/stream.cc > 2) g++ version 1.36.2 (based on GCC 1.36) gets fatal signal 6 and dumps core > when compiling src/Fix.cc > 3) src/String.cc will not compile Exactly the same problems on our Sun4s (gee, fancy that), but the Sun3 version only has problem 3. The messages produced are identical to what occurs for the Sun4s: $ make -k src/libg++.a (cd src; make GXX="g++" GXXFLAGS=" -I/src/gnu/libg++/g++-include -g -O -fstrength-reduce -felide-constructors -fschedule-insns -fdelayed-branch -fsave-memoized -v -pipe" GXXLDFLAGS="-L/src/gnu/libg++/src -lg++ -lm " LIBDIR="/usr/local/gnu/lib" SRCIDIR="/src/gnu/libg++/g++-include" CC="gcc" CFLAGS=" -I/usr/local/gnu/lib/gcc-include -I/usr/include -I/src/gnu/libg++/g++-include -g -O -fstrength-reduce -fdelayed-branch -v -pipe" RANLIB="ranlib" LDXX="/usr/local/gnu/lib/gcc-ld" GXXCRT1="/usr/local/gnu/lib/c rt1+.o" MAKE="make" prefix="/usr/local/gnu" ) g++ -I/src/gnu/libg++/g++-include -g -O -fstrength-reduce -felide-constructors -fschedule-insns -fdelayed-branch -fsave-memoized -v -pipe -c String.cc g++ version 1.36.2 (based on GCC 1.36) /usr/local/gnu/lib/gcc-cpp -+ -v -I/src/gnu/libg++/g++-include -undef -D__GNUC__ -D__GNUG__ -D__cplusplus -Dmc68000 -Dsun -Dunix -D__mc68000__ -D__sun__ -D__unix__ -D__OPTIMIZE__ -Dmc68020 String.cc | /usr/local/gnu/lib/gcc-cc1plus -quiet -dumpbase String.cc -fstrength-reduce -felide-constructors -fschedule-insns -fdelayed-branch -fsave-memoized -g -O -version -o - | /usr/local/gnu/lib/gcc-as -mc68020 -o String.o GNU CPP version 1.36 GNU C++ version 1.36.2 (based on GCC 1.36) (68k, MIT syntax) compiled by GNU C version 1.36. default target switches: -m68020 -mc68020 -mbitfield /src/gnu/libg++/g++-include/String.h: In method StrTmp::StrTmp (struct StrRep *): In file included from String.cc:27: /src/gnu/libg++/g++-include/String.h:413: member `rep' comes from base class needing constructor /src/gnu/libg++/g++-include/String.h: In method StrTmp::StrTmp (class String &): /src/gnu/libg++/g++-include/String.h:415: member `rep' comes from base class needing constructor /src/gnu/libg++/g++-include/String.h: In method StrTmp::StrTmp (class StrTmp &): /src/gnu/libg++/g++-include/String.h:417: member `rep' comes from base class needing constructor String.cc: In method void String::error (char *)const : String.cc:39: warning: `volatile' function does return make[1]: *** [String.o] Error 1 make[1]: Target `all' not remade because of errors. make: *** [src/libg++.a] Error 1 $ Dave -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
T.Day@ucl-cs.UUCP (01/03/90)
From: Tim Day <T.Day@uk.ac.ucl.cs> > Configuration: > Sun-4 SunOS 4.0.3 > g++ 1.36.2 from interviews.stanford.edu > libg++ 1.36.1 from prep.ai.mit.edu > Problems: > 1) g++ version 1.36.2 (based on GCC 1.36) gets fatal signal 6 and dumps core > 3) src/String.cc will not compile Me too (except that libg++ was from labrea). Has anyone had any luck recompiling stuff using g++ 1.36.2 and linking to a libg++ compiled with an old g++ ? A trivial program including only stream.h produces Undefined symbol Filebuf::open(const char *, const char *) referenced from data segment Bizzarely, my libg++.a doesn't seem to contain this, even though it's declared in streambuf.h and implemented in streambuf.cc. Compiling streambuf.o with g++ 1.36.1 on Sun3 gives: nm src/streambuf.o | rsh hyperion g++filt | grep open | grep Filebuf 0000055c T Filebuf::is_open() 000006f8 T Filebuf::open(_iobuf *) 00000582 T Filebuf::open(const char *, io_mode, access_mode) 00000604 T Filebuf::open(const char *, Filebuf) 0000067e T Filebuf::open(int, io_mode) Compiling streambuf.o with g++ 1.36.2 on Sun4 gives: nm src/streambuf.o | rsh hyperion g++filt | grep open | grep Filebuf 00000830 T Filebuf::is_open() 00000a30 T Filebuf::open(_iobuf *) 00000880 T Filebuf::open(const char *, io_mode, access_mode) 00000910 T Filebuf::open(const char *, const char *) 000009a0 T Filebuf::open(int, io_mode) So looks like a change in linkage conventions, or buggy labeling in 1.36.1 (there doesn't seem to be a Filebuf::open(const char *, Filebuf) anywhere). +----------------------------------------------------------------------------+ Tim Day | Meet every second in life as challenge; Department of Photogrammetry | Respond fully to whatever happens UCL, Gower St., London WC1E 6BT | without anxiety, or complaint, or clinging +----------------------------------------------------------------------------+
gnu@G.OSWEGO.EDU (GNU sources) (01/07/90)
Change in linkage conventions is probably the culprit. Michael