Link problem on x86_64 about gperftools HOT 16 CLOSED

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?

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

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

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.

# 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

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.

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!

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.

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

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

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?

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.

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."

} 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.

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)

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.