GCC Bugzilla Bug 25460

Because -nostdlib currently has priority over -pthread, libtool can't build
shared C++ libraries using libpthread. A libtool maintainer told me to file a
bug with GCC. Here's my original email:

-------------------------------------------------------
Subject: C++ shared library with pthread missing symbols
   From: Simon Perreault <nomis80@nomis80.org>
     To: libtool@gnu.org

Why does this create a library with missing symbols?

$ cat testcase.cpp
#include <pthread.h>
void f() { pthread_create(0,0,0,0); }

$ libtool --mode=compile g++ -pthread -c testcase.cpp
mkdir .libs
 g++ -pthread -c testcase.cpp  -fPIC -DPIC -o .libs/testcase.o
 g++ -pthread -c testcase.cpp -o testcase.o >/dev/null 2>&1

$ libtool --mode=link g++ -pthread -rpath /usr/local/lib testcase.lo -o
libtestcase.la
g++ -shared -nostdlib /usr/lib/gcc/i386-redhat-linux/4.1.0/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.1.0/crtbeginS.o  .libs/testcase.o 
-L/usr/lib/gcc/i386-redhat-linux/4.1.0
-L/usr/lib/gcc/i386-redhat-linux/4.1.0/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/i386-redhat-linux/4.1.0/crtendS.o
/usr/lib/gcc/i386-redhat-linux/4.1.0/../../../crtn.o  -pthread -Wl,-soname
-Wl,libtestcase.so.0 -o .libs/libtestcase.so.0.0.0
(cd .libs && rm -f libtestcase.so.0 && ln -s libtestcase.so.0.0.0
libtestcase.so.0)
(cd .libs && rm -f libtestcase.so && ln -s libtestcase.so.0.0.0 libtestcase.so)
ar cru .libs/libtestcase.a  testcase.o
ranlib .libs/libtestcase.a
creating libtestcase.la
(cd .libs && rm -f libtestcase.la && ln -s ../libtestcase.la libtestcase.la)

$ ldd -r .libs/libtestcase.so
undefined symbol: pthread_create        (.libs/libtestcase.so)
        linux-gate.so.1 =>  (0x00799000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x003a3000)
        libm.so.6 => /lib/libm.so.6 (0x00b89000)
        libc.so.6 => /lib/libc.so.6 (0x00cc7000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x008b1000)
        /lib/ld-linux.so.2 (0x00531000)

$ g++ --version
g++ (GCC) 4.1.0 20051212 (Red Hat 4.1.0-0.7)

$ libtool --version
ltmain.sh (GNU libtool) 1.5.20 (1.1220.2.287 2005/08/31 18:54:15)

Thanks!
---------------------------------------------------------------

Here's the reply:

Subject: Re: C++ shared library with pthread missing symbols
   From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>  (Department of Numerical
Simulation, University of Bonn)

I believe pecause -nostdlib will cause gcc not to add -lpthread even if
-pthread is given.  Could you file a bug with the GCC bugzilla (to
either fix the semantics or adjust the documentation)?  Thanks.

It may not be trivial to work around within libtool.  You can
probably LDFLAGS=-lpthread to work around in your special case.

Why are you trying to use -nostdlib ?  If libtool adds it then this is a
libtool bug.

The question whether libtool should use -nostdlib in conjunction with adding
all the other stuff explicitly is surely a valid one, if not completely trivial
and with some interesting corner cases.  It is, however, completely orthogonal
to this bug report.

Documentation for -nostdlib does not suggest that -pthread is not honored any
more.  That is either a documentation bug, if the semantics were desired, or a
driver bug, if not.  Please decide, and fix this.  Then, we may discuss about
libtool semantics (preferably on the libtool lists).

Cheers,
Ralf

The docs say:
No startup files and only the libraries you specify will be passed to the
linker.

So this is not a GCC bug as it says only the libraries you specify will be
passed to the linker, and -pthread is not you specifing a library.

For the casual reader of the documentation, the precedence of this statement
over
| `-pthread'
|      Adds support for multithreading with the "pthreads" library.  This
|      option sets flags for both the preprocessor and linker.

or even the fact that the latter will add a library, are not obvious.  It would
be nice if the documentation could be more definite on both of these points.

BTW, I believe libtool does the -nostdlib stuff because, at least in the past,
not using it could cause situations where later libstdc++ would not be found
automatically.  I think at least for dlopen'ed modules depending on C++
libraries this is still the case (completely untested).

Cheers,
Ralf