gcc vs. g++ for linking with --as-needed. #2

[Peter Volkov <pva at gentoo dot org>]

Hello.

This is second mail with the same subject but I've got some explanations
on related issue [1] and now I try to ask another question.

I have problems linking executable with C++ library. It fails with
undefined reference to pthread_* functions. Here is what I do:

First I compile/link objects which will be included in library:

libtool --mode=compile i686-pc-linux-gnu-g++ -c -g -O2 -pthread sync.cpp 
 i686-pc-linux-gnu-g++ -c -g -O2 -pthread sync.cpp  -fPIC -DPIC -o .libs/sync.o 
 i686-pc-linux-gnu-g++ -c -g -O2 -pthread sync.cpp -o sync.o >/dev/null 2>&1 

All objects I linked in the same way. Next library is linked itself
(I've edited output to simplify reading so there could be some typos):

libtool --mode=link i686-pc-linux-gnu-g++ -o libgigabase_r.la class.lo
  compiler.lo database.lo replicator.lo hashtab.lo file.lo symtab.lo 
  btree.lo rtree.lo cursor.lo query.lo pagepool.lo wwwapi.lo unisock.lo 
  blob.lo container.lo exception.lo localcli.lo sync.lo -pthread
  -rpath /usr/lib -version-info 2
i686-pc-linux-gnu-g++ -shared 
  -nostdlib /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crti.o
  /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtbeginS.o
  .libs/class.o .libs/compiler.o .libs/database.o .libs/replicator.o
  .libs/hashtab.o .libs/file.o .libs/symtab.o .libs/btree.o
  .libs/rtree.o .libs/cursor.o .libs/query.o .libs/pagepool.o
  .libs/wwwapi.o .libs/unisock.o .libs/blob.o .libs/container.o
  .libs/exception.o .libs/localcli.o .libs/sync.o 
  -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2
  -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib
  -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../.. -lstdc++ -lm -lc
  -lgcc_s /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/crtendS.o
  /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crtn.o  -pthread
  -Wl,-soname -Wl,libgigabase_r.so.2 -o .libs/libgigabase_r.so.2.0.0 
(cd .libs && rm -f libgigabase_r.so.2 && ln -s libgigabase_r.so.2.0.0 
  libgigabase_r.so.2) 
(cd .libs && rm -f libgigabase_r.so && ln -s libgigabase_r.so.2.0.0 
  libgigabase_r.so) 
i686-pc-linux-gnu-ar cru .libs/libgigabase_r.a  class.o compiler.o
  database.o replicator.o hashtab.o file.o symtab.o btree.o rtree.o
  cursor.o query.o pagepool.o wwwapi.o unisock.o blob.o container.o
  exception.o localcli.o sync.o 
i686-pc-linux-gnu-ranlib .libs/libgigabase_r.a 
creating libgigabase_r.la 
(cd .libs && rm -f libgigabase_r.la && ln -s ../libgigabase_r.la 
libgigabase_r.la) 


Now I link two programs (subsql and guess) against libgigabase_r.so.
While subsql builds successfully: 

i686-pc-linux-gnu-g++ -c -g -O2 -pthread  subsql.cpp 
i686-pc-linux-gnu-g++ -c -g -O2 -pthread  server.cpp 
libtool --mode=link i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread  -o 
subsql subsql.o server.o libgigabase_r.la 
i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread -o .libs/subsql 
subsql.o server.o  ./.libs/libgigabase_r.so 
creating subsql 


guess do not:

i686-pc-linux-gnu-g++ -c -g -O2 -pthread  guess.cpp 
libtool --mode=link i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread  -o 
guess guess.o libgigabase_r.la 
i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread -o .libs/guess 
guess.o  ./.libs/libgigabase_r.so 
./.libs/libgigabase_r.so: undefined reference to `pthread_key_create' 
./.libs/libgigabase_r.so: undefined reference to `pthread_getspecific' 
./.libs/libgigabase_r.so: undefined reference to `pthread_create' 
./.libs/libgigabase_r.so: undefined reference to `pthread_key_delete' 
./.libs/libgigabase_r.so: undefined reference to `pthread_detach' 
./.libs/libgigabase_r.so: undefined reference to `pthread_setspecific' 
./.libs/libgigabase_r.so: undefined reference to `pthread_join' 
collect2: ld returned 1 exit status 
make: *** [guess] Error 1 


I've looked at object files and found the differences between them. The
object sever.o has pthread_* functions in elf Symbol table (part of
output of readelf -W -a):

00002899  00006602 R_386_PC32             00000000   pthread_create 

and in .symtab: 

   102: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND pthread_create 

So it's clear when programs sources itself contains pthread_ functions
build is successful.

Now I'm not sure if I did anything wrong or is this a bug in gcc/ 
binutils. In my previous letter I wrote that I fixed the problem by
substitution of g++ to gcc. While that is wrong (I think so even though
nobody told me that that fix is wrong) I've compared verbose output of
gcc calls and found that difference in collect output is the following
(well there is a bit more, but this helps collect finish its work):

--no-as-needed -lpthread -lc -lgcc --as-needed

So is this a bug in gcc or in binutils or somewhere else. I'm using
gcc 4.1.2, binutils 2.17.50.0.15.20070418.

Reference on not related discussion:
[1] http://groups.google.com/group/comp.programming.threads/browse_thread/thread/5243754283a02465

Thank you very much for your time,
Peter.

Ð ÐÐÐ, 09/04/2007 Ð 14:37 +0400, Peter Volkov ÐÐÑÐÑ: 
> I've managed to resolve compilation problems with
> LDFLAGS="-Wl,--as-needed" in gigabase [1] package but before I'll report
> upstream I'd like to ensure that my fix is correct.
> 
> Without --as-needed everything compiles and works fine. Before fix
> compilation stopped on error:
> 
> ./libtool --mode=link i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread  -o guess guess.o libgigabase_r.la
> i686-pc-linux-gnu-g++ -Wl,--as-needed -pthread -o .libs/guess guess.o  ./.libs/libgigabase_r.so -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../.. -lstdc++ -lm -lgcc_s -lc -lgcc_s
> ./.libs/libgigabase_r.so: undefined reference to `pthread_create'
> 
> Currently I fixed the problem by changing g++ to gcc
> (i686-pc-linux-gnu-g++ > i686-pc-linux-gnu-gcc) or more rigorously I've
> changed "LD = $(CXX)"  with "LD = $(CC)" in Makefile.in (package without
> automake). But two questions still remains I'm unsure with the answers
> on them:
> 
> 1. Did I understood correctly that the only right way to link is to call
> gcc instead of g++? In google I found page which states the opposite
> [2], so I'm really confused.
> 
> 2. Shall I put -pthread after all objects (after libgigase_r.la) or gcc
> takes care about -lpthread position by itself? This question arose as at
> the beginning I've tried to fix the problem by changing linking order
> and putting -pthread at the end and although this does not fix the
> problem I'm curious does there exit "right" order for -pthread?
> 
> References,
> [1] http://www.garret.ru/~knizhnik/gigabase.html
> [2] http://www.cs.washington.edu/orgs/acm/tutorials/dev-in-unix/compiler.html

Attachment: signature.asc
Description: =?UTF-8?Q?=D0=AD=D1=82=D0=B0?==?UTF-8?Q?_=D1=87=D0=B0=D1=81=D1=82=D1=8C?==?UTF-8?Q?_=D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D1=8F?==?UTF-8?Q?_=D0=BF=D0=BE=D0=B4=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=B0?==?UTF-8?Q?_=D1=86=D0=B8=D1=84=D1=80=D0=BE=D0=B2=D0=BE=D0=B9?==?UTF-8?Q?_=D0=BF=D0=BE=D0=B4=D0=BF=D0=B8=D1=81=D1=8C=D1=8E?=