I have checked that error and it seems that wrong library path was used during compilation. 

original testcase.cpp file was:
#include <pthread.h>

void f(){ pthread_create(0,0,0,0); }

libtool --config | grep _path returns
sys_lib_search_path_spec="/usr/lib/gcc/i686-redhat-linux/4.7.2 /usr/lib /lib "
sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib "
compiler_lib_search_path=""

after correcting -rpath
to libtool --mode=link -rpath /usr/lib -lpthread testcase.lo -o libtestcase.la
all works fine.
$~> libtool --mode=link g++ -rpath /usr/lib -lpthread  testcase.lo -o libtestcase.la
libtool: link: rm -fr  .libs/libtestcase.a .libs/libtestcase.la .libs/libtestcase.lai .libs/libtestcase.so .libs/libtestcase.so.0 .libs/libtestcase.so.0.0.0
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.7.2/crtbeginS.o  .libs/testcase.o   -lpthread -L/usr/lib/gcc/i686-redhat-linux/4.7.2 -L/usr/lib/gcc/i686-redhat-linux/4.7.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-redhat-linux/4.7.2/crtendS.o /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../crtn.o    -Wl,-soname -Wl,libtestcase.so.0 -o .libs/libtestcase.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libtestcase.so.0" && ln -s "libtestcase.so.0.0.0" "libtestcase.so.0")
libtool: link: (cd ".libs" && rm -f "libtestcase.so" && ln -s "libtestcase.so.0.0.0" "libtestcase.so")
libtool: link: ar cru .libs/libtestcase.a  testcase.o
libtool: link: ranlib .libs/libtestcase.a
libtool: link: ( cd ".libs" && rm -f "libtestcase.la" && ln -s "../libtestcase.la" "libtestcase.la" )
$~> ldd -r .libs/libtestcase.so
    linux-gate.so.1 =>  (0xb7730000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb76f7000)
    libstdc++.so.6 => /lib/libstdc++.so.6 (0xb760b000)
    libm.so.6 => /lib/libm.so.6 (0xb75e0000)
    libc.so.6 => /lib/libc.so.6 (0xb742e000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7410000)
    /lib/ld-linux.so.2 (0x4abcd000)
$~>
libtool --config | grep _path returns
sys_lib_search_path_spec="/usr/lib/gcc/i686-redhat-linux/4.7.2 /usr/lib /lib "
sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 /lib /usr/lib "
compiler_lib_search_path=""

after correcting -rpath
to libtool --mode=link -rpath /usr/lib -lpthread testcase.lo -o libtestcase.la
all works fine.
$~> libtool --mode=link g++ -rpath /usr/lib -lpthread  testcase.lo -o libtestcase.la
libtool: link: rm -fr  .libs/libtestcase.a .libs/libtestcase.la .libs/libtestcase.lai .libs/libtestcase.so .libs/libtestcase.so.0 .libs/libtestcase.so.0.0.0
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.7.2/crtbeginS.o  .libs/testcase.o   -lpthread -L/usr/lib/gcc/i686-redhat-linux/4.7.2 -L/usr/lib/gcc/i686-redhat-linux/4.7.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-redhat-linux/4.7.2/crtendS.o /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../crtn.o    -Wl,-soname -Wl,libtestcase.so.0 -o .libs/libtestcase.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libtestcase.so.0" && ln -s "libtestcase.so.0.0.0" "libtestcase.so.0")
libtool: link: (cd ".libs" && rm -f "libtestcase.so" && ln -s "libtestcase.so.0.0.0" "libtestcase.so")
libtool: link: ar cru .libs/libtestcase.a  testcase.o
libtool: link: ranlib .libs/libtestcase.a
libtool: link: ( cd ".libs" && rm -f "libtestcase.la" && ln -s "../libtestcase.la" "libtestcase.la" )
$~> ldd -r .libs/libtestcase.so
    linux-gate.so.1 =>  (0xb7730000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb76f7000)
    libstdc++.so.6 => /lib/libstdc++.so.6 (0xb760b000)
    libm.so.6 => /lib/libm.so.6 (0xb75e0000)
    libc.so.6 => /lib/libc.so.6 (0xb742e000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7410000)
    /lib/ld-linux.so.2 (0x4abcd000)
$~>
$~> g++ --version
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$~> libtool --version
libtool (GNU libtool) 2.4.2
Written by Gordon Matzigkeit <gord.mit.edu>, 1996

Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$~> 

Bug was reported also to libtool:
http://lists.gnu.org/archive/html/bug-libtool/2013-01/msg00018.html

Please reopen -- I believe comment #3 is wrong.  You did:

$ libtool --mode=link -rpath /usr/lib -lpthread testcase.lo -o libtestcase.la

You should have done:

$ libtool --mode=link -rpath /usr/lib -pthread testcase.lo -o libtestcase.la

as in the original bug report and your original post to the libtool list.  Note the substitution -lpthread -> -pthread.

Thanks, I see now.  Discussion in gcc's bugzilla mentioned in comment #1 is
pretty clear.  To sum it up:

  $ libtool --link gcc -pthread ...

Adds -nostdlib (for some historic reasons I'm not 100% aware of) to subsequent
'gcc' invocation.  The '-nostdlib' beats the '-pthread' semantics (which
should usually pass important flags to linker).

---

Gcc documentation says:

| '-nostdlib'
|      Do not use the standard system startup files or libraries when linking.
|      No startup files and only the libraries you specify are passed to the
|      linker, and options specifying linkage of the system libraries, such as
|      '-static-libgcc' or '-shared-libgcc', are ignored.

The -pthread is option which specifies linkage of the system libs.  Thus this
should be handled in libtool (probably, it should parse -pthread option and
add also -lpthread together with -nostdlib, if the -nostdlib is really
important).

Pavel

http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/11704

Hi Pavel,

Can we get this patch in Rawhide until this is fixed upstream?
I bumped into this issue when trying to link collectd against libmemcached, but I expect libmemcached is not the only library affected by this.

Thanks,

Ruben

Ruben, I rally would like to wait for upstream;  still not sure the patch
is correct.  Patching libtool badly downstream ma results in tons of
bad tarballs created by 'make dist'.

I'd rather go the workaround way:  Adjust LDFLAGS to use -lpthread somehow
(or equivalently for other gcc flags).

Hi Pavel,

No problem, thanks for the explanation. We've worked around it in libmemcached for now.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

This tracker probably does not have enough high priority to be investigated, as it is untouched for years already and does not seem to disturb any user. If you have any specific reason, why why should consider fixing this, please feel free to reopen this bug. Thank you.