Solaris and libtool headaches

Sat Dec 18 23:49:00 GMT 1999

I've been trying to get libgcj to build on Solaris x86. Aside from some
minor things that I've already solved, there were two major problems
that came up:
1. When gcj calls "collect2", it specifies LIBGCC_SPEC (ie "-lgcc") on
the command line *twice*. Linux binutils and the Solaris tools don't
seem to care about this, but using recent "official" GNU binutils
snapshots from sourceware it fails with duplicate symbol errors from
libgcc.
For example, to build jv-convert, gcj does:
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/collect2 -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 -o .libs/jv-convert /usr/lib/crt1.o
/usr/lib/crti.o
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/crtbegin.o
-L/home/bryce/projects/libgcj/build/i686-pc-linux-gnu/libjava
[...]
.libs/libgcj.so ./../boehm-gc/.libs/libgcjgc.so
./../zlib/.libs/libzgcj.so --rpath /usr/local/gcc/lib
/tmp/ccxXg1F3main.o -lgcc -lgcj -lm -lgcjgc -lzgcj -ldl -lc -lgcc
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/crtend.o
/usr/lib/crtn.o
2. As we know, libtool doesn't work with C++. It does not generate code
to run C++ static initializers, and executables segfault at runtime
whenever one of these static variables is accessed. Through some miracle
it does work on linux, since it knows to use "gcc --shared" itself, but
on Solaris x86 I was unable to get a working build despite specifying
"--with-ld=/path/to/gnu/ld" on both the gcc and libgcj configure lines,
which has previously been suggested as a work-around. However, if I
create libgcj.so using "gcc --shared" instead of libfool, it just works
- regardless of which linker is used.
So my question is: Given that libtool doesn't work with C++, and is
therefore useless on any platform that doesn't support "gcc --shared",
what use is libtool to us? Wouldn't it save a lot of hassles to just get
rid of it and build libgcj.so directly using "gcc --shared"? If libtool
is essential for some reason, can't we hack it to allways try to build
the shared libs the way it does on linux, regardless of which linker it
thinks is in use? The other option would be to eliminate the use of
static initializers in libgcj, but I don't think that's reasonable.
regards
 [ bryce ]