GCC 4.8.0 linking error

walecha · 04-01-2013, 08:12 AM

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.

1337_powerslacker · 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

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

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

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

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

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

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

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.