Link problem on x86_64

[GoogleCodeExporter]

What steps will reproduce the problem?
1. when compiling Reaim
2.
3.

What is the expected output? What do you see instead?
Without linking -ltcmollac
gcc: -lm: linker input file unused because linking not done
/bin/sh ../libtool --tag=CC --mode=link gcc  -W -Wall -lm -ffloat-store -g
-O -D_GNU_SOURCE -DSHARED_OFILE   -o reaim  driver.o ram.o rand.o
times_ms.o add.o creat_clo.o drv_funcs.o div.o disk_funcs.o pipe_test.o
mul.o num_fcns.o int_fcns.o disk1.o disk_src.o fun.o funcal.o -laio
../lib/libltp.a
gcc -W -Wall -ffloat-store -g -O -D_GNU_SOURCE -DSHARED_OFILE -o reaim
driver.o ram.o rand.o times_ms.o add.o creat_clo.o drv_funcs.o div.o
disk_funcs.o pipe_test.o mul.o num_fcns.o int_fcns.o disk1.o disk_src.o
fun.o funcal.o  -lm -laio ../lib/libltp.a
creat_clo.o: In function `creat_clo':
/autobench/sources/reaim/src/creat_clo.c:573: warning: the use of `mktemp'
is dangerous, better use `mkstemp'
make[2]: Leaving directory `/autobench/sources/osdl-aim-7/src'
make[2]: Entering directory `/autobench/sources/osdl-aim-7'
make[2]: Leaving directory `/autobench/sources/osdl-aim-7'
make[1]: Leaving directory `/autobench/sources/osdl-aim-7'



With -ltcmalloc
/bin/sh ../libtool --tag=CC --mode=link gcc  -W -Wall -lm -ffloat-store -g
-O -D_GNU_SOURCE -ltcmalloc -DSHARED_OFILE   -o reaim  driver.o ram.o
rand.o times_ms.o add.o creat_clo.o drv_funcs.o div.o disk_funcs.o
pipe_test.o mul.o num_fcns.o int_fcns.o disk1.o disk_src.o fun.o funcal.o
-laio ../lib/libltp.a
gcc -W -Wall -ffloat-store -g -O -D_GNU_SOURCE -DSHARED_OFILE -o reaim
driver.o ram.o rand.o times_ms.o add.o creat_clo.o drv_funcs.o div.o
disk_funcs.o pipe_test.o mul.o num_fcns.o int_fcns.o disk1.o disk_src.o
fun.o funcal.o  -lm -ltcmalloc -laio ../lib/libltp.a
creat_clo.o: In function `creat_clo':
/autobench/sources/osdl-aim-7-tcmalloc/src/creat_clo.c:573: warning: the
use of `mktemp' is dangerous, better use `mkstemp'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_key_create'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_once'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_getspecific'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
make[2]: *** [reaim] Error 1
make[2]: Leaving directory `/autobench/sources/osdl-aim-7-tcmalloc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/autobench/sources/osdl-aim-7-tcmalloc'
make: *** [all] Error 2


What version of the product are you using? On what operating system?
google-perftools-0.91.tar.gz
libunwind-snap-070410.tar.gz

On RHEL5 GA and SLES10

Please provide any additional information below.

If export LD_PRELOAD="/usr/local/lib/libtcmalloc.so"

# env
env: symbol lookup error: /usr/local/lib/libtcmalloc.so: undefined symbol:
pthread_key_create

Original issue reported on code.google.com by yca...@gmail.com on 30 Apr 2007 at 8:30

[GoogleCodeExporter]

Hmm, strange.  The simple solution is to just add -pthread to the link line 
(adding
-lpthread or maybe -lpthreads will probably work too).

In theory, this shouldn't be necessary: we provide our own version of
pthread_key_create/etc if there's not one linked in.  But we kind of use black 
magic
to detect that case, so maybe it's not quite working right.  I'll see if I can 
figure
out more.

Out of curiousity, if you use -O2 instead of -O to compile, does that make 
things work?

Original comment by csilv...@gmail.com on 30 Apr 2007 at 8:42

[GoogleCodeExporter]

Using -O2:

gcc: -ltcmalloc: linker input file unused because linking not done
/bin/sh ../libtool --tag=CC --mode=link gcc  -W -Wall -lm -ffloat-store -g -O2
-D_GNU_SOURCE -ltcmalloc -DSHARED_OFILE   -o reaim  driver.o ram.o rand.o 
times_ms.o
add.o creat_clo.o drv_funcs.o div.o disk_funcs.o pipe_test.o mul.o num_fcns.o
int_fcns.o disk1.o disk_src.o fun.o funcal.o -laio ../lib/libltp.a
gcc -W -Wall -ffloat-store -g -O2 -D_GNU_SOURCE -DSHARED_OFILE -o reaim driver.o
ram.o rand.o times_ms.o add.o creat_clo.o drv_funcs.o div.o disk_funcs.o 
pipe_test.o
mul.o num_fcns.o int_fcns.o disk1.o disk_src.o fun.o funcal.o  -lm -ltcmalloc 
-laio
../lib/libltp.a
creat_clo.o: In function `creat_clo':
/autobench/sources/osdl-aim-7-tcmalloc/src/creat_clo.c:573: warning: the use of
`mktemp' is dangerous, better use `mkstemp'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_key_create'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_once'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_getspecific'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
make[2]: *** [reaim] Error 1
make[2]: Leaving directory `/autobench/sources/osdl-aim-7-tcmalloc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/autobench/sources/osdl-aim-7-tcmalloc'
make: *** [all] Error 2

Original comment by yca...@gmail.com on 30 Apr 2007 at 10:28

[GoogleCodeExporter]

Looking at the perftools Makefile, it seems to me like pthread should be linked 
into
libtcmalloc.so.  Can you run
   ldd /usr/local/lib/libtcmalloc.so
and report the results?  Also (and this will be much bigger), attach the output 
of
   nm -D --demangle /usr/local/lib/libtcmalloc.so

Original comment by csilv...@gmail.com on 30 Apr 2007 at 10:51

[GoogleCodeExporter]

I've found one possible problem in the code, where I don't declare weak 
functions
appropriately.  I would expect this to give an error in the LD_PRELOAD case, 
but not
the linking-in case, so I'm still confused, but next version will hopefully be 
a bit
better than this one.

Original comment by csilv...@gmail.com on 1 May 2007 at 12:59

• Changed state: Accepted

[GoogleCodeExporter]

# ldd /usr/local/lib/libtcmalloc.so
        libstacktrace.so.0 => /usr/local/lib/libstacktrace.so.0 (0x00002b1400eee000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b1400ff0000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b14011f1000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b1401347000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b1401577000)
        libunwind.so.7 => /usr/local/lib/libunwind.so.7 (0x00002b1401684000)

Attached nm.out

Original comment by yca...@gmail.com on 7 May 2007 at 3:07

Attachments:

• nm.out

[GoogleCodeExporter]

Hmm, it looks like you don't have pthreads in there anywhere.  The fix we have 
will
help with that, but won't entirely solve it.  Can you also attach your 
config.log
script, after you run configure?  (If it's not too much trouble, you can paste 
in the
configure output as well.)  I wonder if you just don't have pthreads installed 
on
your system somehow.

Original comment by csilv...@gmail.com on 7 May 2007 at 3:35

[GoogleCodeExporter]

I am experiencing a very similar problem and my output of ldd is:

ldd /usr/local/lib/libtcmalloc.so
        linux-gate.so.1 =>  (0xffffe000)
        libstacktrace.so.0 => /usr/local/lib/libstacktrace.so.0 (0xb7eed000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7df6000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7dce000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c8d000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7c81000)
        /lib/ld-linux.so.2 (0x80000000)

Thanks!

Original comment by hatee...@gmail.com on 11 May 2007 at 5:27

[GoogleCodeExporter]

If you could also attach your config.log script (from after you run configure --
maybe attach the configure output as well), I'll take a look and see if I can 
figure
out what's going on.

Original comment by csilv...@gmail.com on 11 May 2007 at 6:14

[GoogleCodeExporter]

similar problem when using google-perftools 0.91 in gentoo 2007.0 amd64 :

$ ldd /usr/local/lib/libtcmalloc.so
        libstacktrace.so.0 => /usr/local/lib/libstacktrace.so.0 (0x00002b52162ee000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6
(0x00002b52163fb000)
        libm.so.6 => /lib/libm.so.6 (0x00002b52165f9000)
        libc.so.6 => /lib/libc.so.6 (0x00002b521674f000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b521698a000)
        libunwind.so.7 => /usr/lib/libunwind.so.7 (0x00002b5216a97000)

and affects both uses of the library (linked or LD_PRELOAD), the output of 
configure
shows :

checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no

the linking problem is solved if added -pthreads as that will link pthreads and 
solve
the weak references

Original comment by care...@gmail.com on 27 May 2007 at 1:01

[GoogleCodeExporter]

Hmm, I continue to be unable to reproduce this.  I'm beginning to suspect libc; 
I
know some libc's, at least, define thread routines.  When I run the following
command, here's the output I get.  Does yours match?

   % nm -D /lib/libc.so.6 | grep -e pthread_once -e pthread_.etspecific -e
pthread_key_create
         w __pthread_getspecific
         w __pthread_key_create
         w __pthread_once
         w __pthread_setspecific

Original comment by csilv...@gmail.com on 27 May 2007 at 1:24

[GoogleCodeExporter]

Another thing for you to try: create a toy program toy.c
   int main() { return 0; }

Then compile it like so:
   gcc -xc toy.c -ltcmalloc
and also try this:
   gcc -xc++ toy.c -ltcmalloc

What does gcc say in each case?  If it successfully compiles, what happens when 
you
try to run ./a.out in each case?

Original comment by csilv...@gmail.com on 27 May 2007 at 2:01

[GoogleCodeExporter]

Ok, never mind.  Looking over the bug report again, I notice the only pthread
routines it's complaining about are the 4 where I had the weak definitions 
wrong.  I
now believe that by fixing those, I'll address this problem.  Please let me 
know if
you see the linker complaining about any pthread routine other than the 4 in the
initial bug report.  Otherwise, I'll assume my fix -- out next release, which 
I'll
try to make soon -- will resolve this issue.

Original comment by csilv...@gmail.com on 27 May 2007 at 2:07

• Changed state: Started

[GoogleCodeExporter]

On RedHat EL 4.4, the configure script fails to detect the pthreads lib and 
omits -
lpthread.  A cheap and easy fix for this is to change the search order in the 
configure script so "lpthread" preceds "lpthreads."

Original comment by aby...@gmail.com on 5 Jun 2007 at 9:20

[GoogleCodeExporter]

} A cheap and easy fix for this is to change the search order in the
} configure script so "lpthread" preceds "lpthreads."

The order of checking was determined by the author of the PTHREADS macro, not 
us, and
I don't know what the repercussions are of changing the order.  My understanding
looking at the code is that the order was carefully chosen.

I don't understand how changing the order would help in the case you describe,
though.  Are you saying that lpthreads exists on your machine, but doesn't do
anything useful, so you want it to match lpthread first?  It would be great if 
you
could be a bit more specific about the problem you're seeing, and the solution.

Also, this appears to be unrelated to the above problem, so you may want to 
file a
new bug report.

Original comment by csilv...@gmail.com on 5 Jun 2007 at 9:24

[GoogleCodeExporter]

Same here on x86_64 RHEL4

[root@lnxp-1020:/data/njuenemann/devel/mysql/google-perftools-0.8]$ ldd -r
./.libs/libtcmalloc.so
        libstacktrace.so.0 =>
/data/njuenemann/devel/mysql/google-perftools-0.8/.libs/libstacktrace.so.0
(0x0000002a956fa000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000002a95806000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a959f6000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95b7d000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a95db1000)
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
undefined symbol: pthread_getspecific   (./.libs/libtcmalloc.so)
undefined symbol: pthread_once  (./.libs/libtcmalloc.so)
undefined symbol: pthread_key_create    (./.libs/libtcmalloc.so)
undefined symbol: pthread_setspecific   (./.libs/libtcmalloc.so)

I'm added -lpthread to PTHREAD_LIBS in Makefile, afterwards libtcmalloc.so is
correctly linked against libpthread.

[root@lnxp-1020:/data/njuenemann/devel/mysql/google-perftools-0.8]$ ldd -r
./.libs/libtcmalloc.so
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a95705000)
        libstacktrace.so.0 =>
/data/njuenemann/devel/mysql/google-perftools-0.8/.libs/libstacktrace.so.0
(0x0000002a9581a000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000002a9591b000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95b0c000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a95c92000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a95ec6000)
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)

Original comment by juenem...@gmail.com on 12 Jul 2007 at 6:43

[GoogleCodeExporter]

OK, perftools 0.92 is out, with better weak definitions for the pthread 
functions. 
I'm hoping this fixes the problem! -- hoping enough to close the bug, in fact. 
:-) 
If it turns out the problem is still there, please reopen.

Original comment by csilv...@gmail.com on 19 Jul 2007 at 2:41

• Changed state: Fixed