LinuxQuestions.org - GCC 4.8.0 linking error

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - GCC 4.8.0 linking error (https://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.

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 (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

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)

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.

marbangens

04-04-2013 10:44 AM

I gott this from compiling gnash

Code:

 CXXLD  dump-gnash

/usr/lib64/gcc/x86_64-slackware-linux/4.8.0/../../../../x86_64-slackware-linux/bin/ld: dump_gnash-gnash.o: undefined reference to symbol'_ZN5boost6system15system_categoryEv'

/usr/lib64/gcc/x86_64-slackware-linux/4.8.0/../../../../x86_64-slackware-linux/bin/ld: note: '_ZN5boost6system15system_categoryEv' is defined in DSO /usr/lib64/../lib64/libboost_system.so.1.53.0 so try adding it to the linker command line

/usr/lib64/../lib64/libboost_system.so.1.53.0: could not read symbols: Invalid operation

collect2: error: ld returned 1 exit status

what dose DSO mean?

willysr

04-04-2013 10:46 AM

Dynamic Shared Object

a4z	04-04-2013 10:50 AM

Quote:

Originally Posted by Buumi (Post 4924991)

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

no, seems that someone is calling boost::tread.interupt what throws an exception which should be caught in the tread code but is not caught

code should look like here, taken from there http://www.highscore.de/cpp/boost/multithreading.html

Code:

#include <boost/thread.hpp> 

#include <iostream> 



void wait(int seconds) 

{ 

  boost::this_thread::sleep(boost::posix_time::seconds(seconds)); 

} 



void thread() 

{ 

  try 

  { 

    for (int i = 0; i < 5; ++i) 

    { 

      wait(1); 

      std::cout << i << std::endl; 

    } 

  } 

  catch (boost::thread_interrupted&) 

  { 

  } 

} 



int main() 

{ 

  boost::thread t(thread); 

  wait(3); 

  t.interrupt(); 

  t.join(); 

}

marbangens

04-04-2013 11:13 AM

Code:

note: '_ZN5boost6system15system_categoryEv' is defined in DSO /usr/lib64/../lib64/libboost_system.so.1.53.0 so try adding it to the linker command line

dose this mean I should use -lboost_system to LDFLAGS? how do I know that?

a4z	04-04-2013 12:13 PM

Quote:

Originally Posted by marbangens (Post 4925099)

Code:

note: '_ZN5boost6system15system_categoryEv' is defined in DSO /usr/lib64/../lib64/libboost_system.so.1.53.0 so try adding it to the linker command line

dose this mean I should use -lboost_system to LDFLAGS? how do I know that?

jes, boost system is required in newer boost versions (if you use for example thread library, asio, ... some more)

Neil65

04-10-2013 05:36 PM

Not directly related to the original topic, but I'm encountering another issue with gcc 4.8.0. If I compile the kernel (3.6.x and 3.8.x) then one of my laptops (HP 6715b) with a R300 chipset will oops at radeon_vmap_location+0x14. Roll back to gcc 4.7.2 and everything is fine. I have a newer laptop with an R600 and it is fine with either compiler. Perhaps the new gcc is exposing an issue with the radeon code. Maybe the other way around.

adamk75

04-10-2013 06:44 PM

Quote:

Originally Posted by Neil65 (Post 4929365)

You should definitely report that to the radeon driver developers. Mentioning it in #radeon on Freenode is a good start.

All times are GMT -5. The time now is 09:53 PM.