Bug 661333 - libtool uses -nostdlib linking c++ targets
Summary: libtool uses -nostdlib linking c++ targets
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: libtool
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Ondrej Dubaj
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 661115
TreeView+ depends on / blocked
 
Reported: 2010-12-08 15:31 UTC by Rex Dieter
Modified: 2021-10-05 10:42 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-05 10:42:44 UTC
Type: ---


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 25460 0 None None None 2019-03-13 09:21:22 UTC

Description Rex Dieter 2010-12-08 15:31:15 UTC
Per http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460

c++ shlib targets using -pthread flag end up not linking -lpthread due to libtool's use of -nostdlib in this context, resulting in libraries with undefined symbols.

Comment 1 Petr Hracek 2013-01-28 08:40:19 UTC
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@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.
$~> 

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

Comment 2 Andy Lutomirski 2013-09-04 20:01:53 UTC
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.

Comment 3 Pavel Raiskup 2013-09-11 08:17:06 UTC
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

Comment 5 Ruben Kerkhof 2013-12-14 13:16:05 UTC
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

Comment 6 Pavel Raiskup 2013-12-16 11:30:08 UTC
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).

Comment 7 Ruben Kerkhof 2013-12-17 08:13:06 UTC
Hi Pavel,

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

Comment 8 Jan Kurik 2015-07-15 15:17:58 UTC
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

Comment 9 Mike McCune 2016-03-28 23:21:47 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 10 Fedora End Of Life 2016-11-24 10:28:49 UTC
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.

Comment 11 Fedora Admin user for bugzilla script actions 2021-07-01 15:31:26 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 12 Ondrej Dubaj 2021-10-05 10:42:27 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.