GNU bug report logs - #13550
problem with linking libpthread

From: Petr Hracek <phracek <at> redhat.com>
To: bug-libtool <at> gnu.org
Subject: problem with linking libpthread
Date: Fri, 25 Jan 2013 17:57:51 +0100

Hi Folks,

I have received bug which seems to be relevant to libtool
https://bugzilla.redhat.com/show_bug.cgi?id=661333

it refers to:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460

$ ~> cat testcase.cpp
#include <pthread.h>

void f(){ pthread_create(0,0,0,0); }
$ ~> libtool --mode=compile g++ -pthread -c testcase.cpp
libtool: compile:  g++ -pthread -c testcase.cpp  -fPIC -DPIC -o 
.libs/testcase.o
libtool: compile:  g++ -pthread -c testcase.cpp -o testcase.o >/dev/null 
2>&1
$ ~> libtool --mode=link g++ -pthread -rpath /lib/ testcase.lo -o 
libtestcase.la
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 
-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  -pthread -pthread 
-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 =>  (0xb7719000)
    libstdc++.so.6 => /lib/libstdc++.so.6 (0xb760e000)
    libm.so.6 => /lib/libm.so.6 (0xb75e3000)
    libc.so.6 => /lib/libc.so.6 (0xb7431000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7414000)
    /lib/ld-linux.so.2 (0x4abcd000)
undefined symbol: pthread_create    (.libs/libtestcase.so)
$ ~>

library libpthread is not linking with my object file

versions of libtool and g++ are:
$ ~> libtool --version
libtool (GNU libtool) 2.4.2
Written by Gordon Matzigkeit <gord <at> gnu.ai.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.
$ ~> 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.

$ ~>

How can it be solved? It seems to be a bug in libtool, right?
Can it be a problem with ordering of lib flags in libtool?

-- 
S pozdravem / Best regards

Petr Hracek

Red Hat Czech s.r.o.
BaseOS Core Services Brno

Email:phracek <at> redhat.com
Web:www.cz.redhat.com





From: Roumen Petrov <bugtrack <at> roumenpetrov.info>
To: 13550 <at> debbugs.gnu.org
Subject: Re: bug#13550: problem with linking libpthread
Date: Fri, 25 Jan 2013 23:44:58 +0200

Petr Hracek wrote:
> Hi Folks,
>
> I have received bug which seems to be relevant to libtool
> https://bugzilla.redhat.com/show_bug.cgi?id=661333
> []
>
> How can it be solved? 
Dunno.

> It seems to be a bug in libtool, right?
No. All is fine in my environment where most of packages are without 
vendor patches and linux distribution is different.

> Can it be a problem with ordering of lib flags in libtool?
May be you cannot use -rpath /lib in you build environment (1% 
probability).

Check libtool configuration for search path
$ libtool --config | grep _path

Note if you change compiler you must rebuild libtool.
Some projects force root library directory to be before user path in 
'library search path' and usual result is link failure.

Roumen





From: Petr Hracek <phracek <at> redhat.com>
To: bug-libtool <at> gnu.org
Subject: Re: bug#13550: problem with linking libpthread
Date: Mon, 28 Jan 2013 09:33:00 +0100

Hello,

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)
$~>

Thank you

best regards
Petr


On 01/25/2013 10:44 PM, Roumen Petrov wrote:
> Petr Hracek wrote:
>> Hi Folks,
>>
>> I have received bug which seems to be relevant to libtool
>> https://bugzilla.redhat.com/show_bug.cgi?id=661333
>> []
>>
>> How can it be solved? 
> Dunno.
>
>> It seems to be a bug in libtool, right?
> No. All is fine in my environment where most of packages are without 
> vendor patches and linux distribution is different.
>
>> Can it be a problem with ordering of lib flags in libtool?
> May be you cannot use -rpath /lib in you build environment (1% 
> probability).
>
> Check libtool configuration for search path
> $ libtool --config | grep _path
>
> Note if you change compiler you must rebuild libtool.
> Some projects force root library directory to be before user path in 
> 'library search path' and usual result is link failure.
>
> Roumen
>
>
>
>
> _______________________________________________
> Bug-libtool mailing list
> Bug-libtool <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-libtool





From: Pavel Raiskup <praiskup <at> redhat.com>
To: libtool-patches <at> gnu.org
Cc: 13550 <at> debbugs.gnu.org, bugtrack <at> roumenpetrov.info, phracek <at> redhat.com
Subject: [PATCH] libtool: handle the -pthread{,s} options for g++
Date: Thu, 28 Nov 2013 15:18:05 +0100

As we are forced to pass -nostdlib to g++ for linking, this option
expectedly disables the effectiveness of passed -pthread flag - so
add the -lpthread explicitly to $deplibs to link correctly.

References:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460
https://bugzilla.redhat.com/show_bug.cgi?id=661333
http://lists.gnu.org/archive/html/bug-libtool/2013-01/msg00018.htm

* build-aux/ltmain.in (func_mode_link): Explicitly add -lpthread
flag into $deplibs when -pthread is passed (for g++ only).
---
 build-aux/ltmain.in | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index fba05c1..f202b80 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5113,6 +5113,16 @@ func_mode_link ()
 	    *" $arg "*) ;;
 	    * ) func_append new_inherited_linker_flags " $arg" ;;
 	esac
+
+	# As we are forced to pass -nostdlib to g++ during linking, the option
+	# -pthread{,s} is not in effect;  add the -lpthread to $deplist
+	# explicitly to link correctly.
+	if test "$tagname" = CXX -a x"$with_gcc" = xyes; then
+	  case "$arg" in
+	    -pthread*) func_append deplibs " -lpthread" ;;
+	  esac
+	fi
+
 	continue
 	;;
 
-- 
1.8.4.2





From: Mihai Moldovan <ionic <at> ionic.de>
To: 13550 <at> debbugs.gnu.org
Subject: Re: [PATCH] libtool: handle the -pthread{,s} options for g++
Date: Fri, 5 Apr 2019 11:49:14 +0200

[Message part 1 (text/plain, inline)]
Hi Pavel


I am afraid this patch WILL lead to breakage on systems that do not have a
library called "pthread" and use the GCC suite/g++. Another point of discussion
might be if libtool should catch situations in which users explicitly(!) set
both the -nostdlib and -pthread(s) compiler flags and add appropriate library
dependencies, but that might be too much magic.

Finding the actual library implementing portable threads support is non-trivial,
which is why helpers like AX_PTHREAD exist. For instance, some systems put the
implementation in libpthread.sharedext, while others put it in
libpthreads.sharedext (note the additional s) and even others put it into libc
directly without a special library (e.g., Darwin). Worse, there are systems out
there (or have existed historically) like DEC UNIX that have both a
libpthread.sharedext and libpthreads.sharedext library, with the former
implementing the proper portable threads standard, while the latter
implements... something called DECthreads based on the CMA (Compaq-proprietary)
and DCE threaded (some early POSIX draft(!)) interfaces.


I'll submit a patch to the GNU Autoconf Archive to work around that bug in
AX_PTHREAD by adding the first found pthread library to PTHREAD_LIBS if gcc is
being used (as the C compiler, anyway, because AX_PTHREAD always checks using C,
which should be mostly fine, but that's a different topic) and the -pthread
compiler flag is being checked as candidate for enabling pthread support.


Nevertheless, this bug has been around for more than 10 years now and I'd really
like to finally see it fixed, because working around it is getting really old.



Mihai


[signature.asc (application/pgp-signature, attachment)]

GNU bug report logs - #13550 problem with linking libpthread

GNU bug report logs - #13550
problem with linking libpthread