[Sorry to hit two lists (I took out binutils after some thought and reading), but I don't know where the real problem lies. Current guess is in libtool 1.3.4 as used by libstdc++-v3.] On some platforms, under some gcc configurations, a -[p]thread[s] switch is honored to make C++ thread-safe. In some cases, this switch will force the gcc driver to provide an additional library to ld which exposes the POSIX thread (or whatever threading library) interface. For example, last I looked, Solaris and Linux both work this way. In other cases, the use of this switch will force the gcc driver to provide an alternate libc implementation to ld which is thread-safe and which exposes the POSIX thread. For example, FreeBSD 3.4 uses libc_r instead of libc when -pthread is given to gcc. In particular, on this latter type of platform, it is *not* correct for libstdc++ to be built tightly bound to libc since libc is conditionally replaced with libc_r (which contains the same symbols as libc) at a later link-time. Here is the libtool command line: /bin/sh ../libtool --mode=link "/usr/tmp/egcs-freebsdelf3.4/gcc/xgcc -B/usr/tmp/egcs-freebsdelf3.4/gcc/ -B/usr/local/beta-gcc/i686-unknown-freebsdelf3.4/bin/" -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -Werror -g -o libstdc++.la -rpath /usr/local/beta-gcc/lib -version-info 3:0:0 -lm limitsMEMBERS.lo c++io.lo cmath.lo complex.lo complexf.lo complexl.lo complex_io.lo stdexcept.lo ios.lo stdstreams.lo strstream.lo locale.lo localename.lo locale-inst.lo stl-inst.lo misc-inst.lo valarray-inst.lo ../math/libmath.la ../libio/libio.la libinst-string.la Here is the command line constructed and run to create the shared library: /usr/tmp/egcs-freebsdelf3.4/gcc/xgcc -B/usr/tmp/egcs-freebsdelf3.4/gcc/ -B/usr/local/beta-gcc/i686-unknown-freebsdelf3.4/bin/ -shared limitsMEMBERS.lo c++io.lo cmath.lo complex.lo complexf.lo complexl.lo complex_io.lo stdexcept.lo ios.lo stdstreams.lo strstream.lo locale.lo localename.lo locale-inst.lo stl-inst.lo misc-inst.lo valarray-inst.lo -Wl,--whole-archive ../math/.libs/libmath.al ../libio/.libs/libio.al .libs/libinst-string.al -Wl,--no-whole-archive -lm -lc -Wl,-soname -Wl,libstdc++.so.3 -o .libs/libstdc++.so.3 Using a very recent GNU binutils on the 2.10 branch, this inserts whatever ELFisms are required to force libc to be pulled in whenever libstdc++ is pulled in. Given all the documentation I have read, this is correct behavior given the above command line. Unfortunately, this means that I get both libc and libc_r when -pthread is given to g++ later. If I manually take out the -lm and -lc in the second command line, I get a shared libstdc++ library that appears to work just fine when either libc or libc_r is provided by the g++ driver at later link-times. Is this solution on the right track? Regards, Loren
