LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   GCC 4.8.0 linking error (http://www.linuxquestions.org/questions/slackware-14/gcc-4-8-0-linking-error-4175456369/)

walecha 04-01-2013 08:12 AM

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.

mattallmill 04-01-2013 09:16 AM

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.

willysr 04-01-2013 09:56 AM

Whenever you encountered an error with GCC 4.8.0, please consult with this PORTING GUIDE

ponce 04-01-2013 10:33 AM

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.

fskmh 04-01-2013 11:31 AM

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.

ponce 04-01-2013 11:40 AM

Quote:

Originally Posted by fskmh (Post 4922857)
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.

larryhaja 04-01-2013 07:21 PM

Quote:

Originally Posted by walecha (Post 4922722)
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"

a4z 04-02-2013 02:15 AM

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

walecha 04-02-2013 07:52 PM

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.

ppr:kut 04-03-2013 01:08 AM

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 :)

walecha 04-03-2013 07:37 AM

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 :cool:

GazL 04-03-2013 08:01 AM

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?

volkerdi 04-03-2013 10:30 AM

Quote:

Originally Posted by GazL (Post 4924266)
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. ;)

GazL 04-03-2013 11:20 AM

Quote:

Originally Posted by volkerdi (Post 4924356)
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. ;)

Buumi 04-04-2013 08:45 AM

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.


All times are GMT -5. The time now is 07:40 PM.