dwf%hope@lanl.gov (David W. Forslund) (10/17/89)
I've tried compiling the 1.36.0- version of libg++ on a Sun3 running OS4.0.3 and have had troubles. First, sun3 isn't defined by the compiler so that EH.cc fails in setjmp.h. This is easy to fix with -Dsun3, but it shouldn't be necessary. Second, I'm getting duplicate definition of symbols: ___do_global_cleanup ___do_global_init in crt0.c and gnulib3.c. crt0+.o was not installed by g++. If I don't install it, I get an error message of not being able to find crt0+.o. If I install it I get the error message of duplicate definitions. Where did gnulib3.c come from? I don't see it anywhere. Why are the compile and install of crt0+.o commented out in the Makefile? I also had to install gas in /usr/local/lib/gcc-as to get things to assemble with -pipe. This needs to be better documented, particularly as to where to install gas. David Forslund MS E531 Los Alamos National Laboratory Los Alamos, NM 87545 (505) 665-1907 (dwf@lanl.gov)
dwf%hope@LANL.GOV (David W. Forslund) (10/17/89)
I regard to the problem with g++ having duplicate definitions, I have discovered something. Apparently you are not supposed to use g++ to compile C++ programs, but rather gcc itself. By changing the compiler in the tests directory to gcc instead of g++, I got the test programs to compile! I think that gcc normally should not be compiling C++ programs and that g++ should be used to compile C++ programs. This new behavior of g++1.36.0- seems highly abherent and undesirable. David Forslund MS E531 Los Alamos National Laboratory Los Alamos, NM 87545 (505) 665-1907 (dwf@lanl.gov)
scp@SFI.SANTAFE.EDU ("Stephen C. Pope") (10/17/89)
One of the more significant problems with the all-in-one gcc for compiling C and C++ shows up in SunOS 4.X systems, where shared libraries are available. gcc must use either the Sun- supplied ld (which supports shared libraries), or gnu ld, which does not support shared libraries, but is essential for loading G++ code, due to the introduction of __main() and the current style of static constructor/destructor invocation. I'm willing to accept that I can only link my g++ code statically (I'm always debugging it anyway!), but that I should have to accept static library loading for all my routine C compilation work is definitely offensive. I value gcc highly for compiling all sorts of stuff - emacs, common tex, X, etc, and the additional disk- and run time core-usage is not a welcome bonus. a GNU ld that supports shared libraries would be a welcome event, of course, but... As I'm also frequently suffling code between the AT&T and GNU C++ compilers, the .c <-> .cc issue gets tiresome also; I can fix CC to eat .cc suffixes, but not everyone has that luxury. Stephen Pope Santa Fe Institute scp@sfi.santafe.edu