[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
