LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 04-01-2013, 08:12 AM   #1
walecha
LQ Newbie
 
Registered: Jan 2010
Location: Malang
Distribution: slackware
Posts: 11

Rep: Reputation: 0
GCC 4.8.0 linking error


Today I was testing out sddm on slackware-current (using the latest update). But I got linking error like this:

Code:
/usr/lib/gcc/i486-slackware-linux/4.8.0/../../../../i486-slackware-linux/bin/ld: CMakeFiles/sddm.dir/daemon/Authenticator.cpp.o: undefined reference to symbol '__pthread_key_create@@GLIBC_2.0'
/usr/lib/gcc/i486-slackware-linux/4.8.0/../../../../i486-slackware-linux/bin/ld: note: '__pthread_key_create@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line
/lib/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: *** [src/sddm] Error 1
make[2]: Leaving directory `/tmp/wlsbuild/sddm-0.1.0/build'
make[1]: *** [src/CMakeFiles/sddm.dir/all] Error 2
make[1]: Leaving directory `/tmp/wlsbuild/sddm-0.1.0/build'
make: *** [all] Error 2
I was able to build the program without error by adding LDFLAGS="-lpthread" before cmake.

Is this a bug on slackware-current gcc's? I've reported this to sddm developer but they couldn't reproduce the issue, or their build was just fine #51.

Any idea?

PS: Just FYI, sddm developer has been working on a pamless sddm and I'm currently using it right now.

Last edited by walecha; 04-01-2013 at 08:14 AM. Reason: add the issue report url
 
Old 04-01-2013, 09:16 AM   #2
mattallmill
Member
 
Registered: Nov 2009
Location: 127.0.0.1
Distribution: Slackware
Posts: 151

Rep: Reputation: 18
IMO, gcc-4.8.0 is not quite ready for prime time. I tried to compile a couple of packages, and it stopped with errors. When I went back to 4.7.2, they compiled without error. So until the 4.8.x series matures a bit more, I think that 4.7.2 is the better choice.
 
Old 04-01-2013, 09:56 AM   #3
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 2,353

Rep: Reputation: 378Reputation: 378Reputation: 378Reputation: 378
Whenever you encountered an error with GCC 4.8.0, please consult with this PORTING GUIDE
 
1 members found this post helpful.
Old 04-01-2013, 10:33 AM   #4
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,314

Rep: Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816
from the experiments done here, a lot of stuff (but not everything) I built from SBo using qt needed explicit linking to libpthread with gcc-4.8.0.

Last edited by ponce; 04-01-2013 at 03:52 PM.
 
Old 04-01-2013, 11:31 AM   #5
fskmh
Member
 
Registered: Jun 2002
Location: South Africa
Distribution: Slackware64-current multilib
Posts: 225

Rep: Reputation: 52
I've had that error a few times as well, and I either add -lpthread to LDFLAGS or explicitly add it to the linking rule in the Makefile.

I don't think it's that gcc 4.8.0 is somehow defective, I think it's simply that newer versions of gcc tend to tighten up loose ends where things are vague or implicit but now manifest themselves as a compile-time error like this one.
 
Old 04-01-2013, 11:40 AM   #6
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,314

Rep: Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816
Quote:
Originally Posted by fskmh View Post
I don't think it's that gcc 4.8.0 is somehow defective, I think it's simply that newer versions of gcc tend to tighten up loose ends where things are vague or implicit but now manifest themselves as a compile-time error like this one.
yes, I think the various upstreams have to do some patching.
 
Old 04-01-2013, 07:21 PM   #7
larryhaja
Member
 
Registered: Jul 2008
Distribution: Slackware 13.1
Posts: 291

Rep: Reputation: 75
Quote:
Originally Posted by walecha View Post
Today I was testing out sddm on slackware-current (using the latest update). But I got linking error like this:

Code:
/usr/lib/gcc/i486-slackware-linux/4.8.0/../../../../i486-slackware-linux/bin/ld: CMakeFiles/sddm.dir/daemon/Authenticator.cpp.o: undefined reference to symbol '__pthread_key_create@@GLIBC_2.0'
/usr/lib/gcc/i486-slackware-linux/4.8.0/../../../../i486-slackware-linux/bin/ld: note: '__pthread_key_create@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line
/lib/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: *** [src/sddm] Error 1
make[2]: Leaving directory `/tmp/wlsbuild/sddm-0.1.0/build'
make[1]: *** [src/CMakeFiles/sddm.dir/all] Error 2
make[1]: Leaving directory `/tmp/wlsbuild/sddm-0.1.0/build'
make: *** [all] Error 2
I was able to build the program without error by adding LDFLAGS="-lpthread" before cmake.

Is this a bug on slackware-current gcc's? I've reported this to sddm developer but they couldn't reproduce the issue, or their build was just fine #51.

Any idea?

PS: Just FYI, sddm developer has been working on a pamless sddm and I'm currently using it right now.
Yeah, I ran into this trying to compile avogadro with -lpthread linking error on Slackware64-current. I added the following to the cmake step.
Code:
-DCMAKE_SHARED_LINKER_FLAGS="-lpthread"
 
Old 04-02-2013, 02:15 AM   #8
a4z
Member
 
Registered: Feb 2009
Posts: 277

Rep: Reputation: 111Reputation: 111
I think it is (also) a good idea to add -pthread to the CMAKE_CXX_FLAGS

from man gcc:
Adds support for multithreading with the pthreads library. This option sets flags for both the preprocessor and linker.

at least for my projects this did it, and I think it is required to enable some c++11 thread support parts
 
Old 04-02-2013, 07:52 PM   #9
walecha
LQ Newbie
 
Registered: Jan 2010
Location: Malang
Distribution: slackware
Posts: 11

Original Poster
Rep: Reputation: 0
Thanks for the answers

Well, at least now I know that I'm not alone in this :-P
Quote:
Originally Posted by a4z
I think it is (also) a good idea to add -pthread to the CMAKE_CXX_FLAGS
I think I'll play with it for a while. Thanks for the hint a4z.
 
Old 04-03-2013, 01:08 AM   #10
ppr:kut
Member
 
Registered: Aug 2006
Location: Netherlands
Distribution: Slackware
Posts: 353

Rep: Reputation: 89
This has actually nothing to do with the gcc bump. It is an issue with ld. An upstream change there broke linking dynamic libraries through weak symbols. They consider it a change, but from what I could see most distributions consider it a bug and revert the change. Expect that to be handled in -current soon too
 
Old 04-03-2013, 07:37 AM   #11
walecha
LQ Newbie
 
Registered: Jan 2010
Location: Malang
Distribution: slackware
Posts: 11

Original Poster
Rep: Reputation: 0
It has been fixed

I think this "bug" has been fixed in the latest update in slackware-current,
Code:
Wed Apr  3 06:58:59 UTC 2013
d/binutils-2.23.52.0.1-i486-2.txz:  Rebuilt.
  Export/install demangle.h.  Thanks to Jim Diamond.
  Patched addr2line to use dynamic symbol table if needed.
  Reverted an upstream change that broke linking dynamic libraries through
  weak symbols, requiring additions like -lpthread to the link line.
  Fixed texinfo files to be compatible with newer texinfo versions.
  Patched system headers to not complain about missing "config.h".
rsync is a must for tonight
 
Old 04-03-2013, 08:01 AM   #12
GazL
Senior Member
 
Registered: May 2008
Posts: 3,231

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
Hmmm. I'm not sure about this one. I tend to agree with upstream that the new behaviour, however disruptive is more correct. is it really wise to have the linker pull in things that you didn't tell it to?
 
Old 04-03-2013, 10:30 AM   #13
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 836

Rep: Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620
Quote:
Originally Posted by GazL View Post
Hmmm. I'm not sure about this one. I tend to agree with upstream that the new behaviour, however disruptive is more correct. is it really wise to have the linker pull in things that you didn't tell it to?
Upstream couldn't exactly agree on this, even. H.J. Lu thought it was a gcc bug at first and reported it there.

Personally, I have to go with the notion that if the change causes existing code to fail to compile until you make a change to the Makefile/configure/whatever that has the identical effect as reverting the binutils commit does, then it is not a beneficial change. I've never been a big supporter of making something more correct for no actual benefit and having breakage result. The time to make something more correct is before the behavior is long-established in the real world.

Guess I'd make a lousy CS professor.
 
2 members found this post helpful.
Old 04-03-2013, 11:20 AM   #14
GazL
Senior Member
 
Registered: May 2008
Posts: 3,231

Rep: Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828Reputation: 828
Quote:
Originally Posted by volkerdi View Post
The time to make something more correct is before the behavior is long-established in the real world.
No argument from me on that one. Pity it rarely seems to happen that way around.
 
Old 04-04-2013, 08:45 AM   #15
Buumi
Member
 
Registered: Dec 2010
Distribution: Slackware
Posts: 46

Rep: Reputation: 5
Could my problem be related to this?
I'm trying to run Spring RTS 94.1. It compiles fine on slackware64-current, but I can't run it. It crashes with error
Code:
[f=0000000] Error: Segmentation fault (SIGSEGV) in spring 94.1 (OMP)
[f=0000000] Error: Stacktrace:
[f=0000000] Error:   <0> /lib64/libpthread.so.0(+0xf580) [0x7f561c1e5580]
[f=0000000] Error:   <1> "./spring"() [0xa23b50]
[f=0000000] Error:   <2> "./spring"() [0xa297fd]
[f=0000000] Error:   <3> ??:?
[f=0000000] Error:   <4> /lib64/libpthread.so.0(+0x7eaf) [0x7f561c1ddeaf]
[f=0000000] Error:   <5> /lib64/libc.so.6(clone+0x6d) [0x7f5618a2d58d]
terminate called after throwing an instance of 'boost::thread_interrupted'
Aborted
I also tried to compile 94.0 and it has the same problem but that version worked before my upgrade on 27th March. I'm still having this problem, even after upgrade to latest current. I guess I should reinstall current to be sure it's not something I've messed up.
 
  


Reply

Tags
error, gcc, linking


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
gcc -linking brmchess Linux - Newbie 3 03-02-2012 01:30 AM
GCC Static linking error CartmanYO Programming 2 06-11-2010 02:28 AM
static linking in gcc lavixu Linux - Newbie 1 11-27-2009 07:07 AM
gcc linking error. ugenn Linux - Software 0 01-22-2003 11:18 PM
Linking without gcc, but with ld gluon Programming 3 05-29-2002 05:11 AM


All times are GMT -5. The time now is 07:33 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration