Errors are similar to: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: lib/.libs/libstardict.a(pluginmanager.o): undefined reference to symbol 'g_module_symbol' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'g_module_symbol' is defined in DSO /usr/lib64/libgmodule-2.0.so.0 so try adding it to the linker command line /usr/lib64/libgmodule-2.0.so.0: could not read symbols: Invalid operation or /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: usb.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'pthread_create@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation gcc version does not matter (i reproduced these with 4.7.2). binutils-2.23.1 works. this looks a lot like the errors you get with --no-copy-dt-needed-entries (aka --no-add-needed), and adding --add-needed fixes it. did they change the default or something?
The default changed to --no-copy-dt-needed-entries back in 2.22. Why we're hitting it now I don't know. The only commit related to it in 2.23.2 I can find is http://sourceware.org/ml/binutils/2012-12/msg00060.html but reverting it doesn't help.
i want to say behavior related to weak symbols has changed ... might be related i first posted this in Bug 458164. but i'm not sure these are bugs in binutils itself vs the packages missing linking ... we probably should unkeyword 2.23.2 though until we understand the issue better and have a concrete plan.
Commit message: Dekeyword until we can get a handle on missing symbol linkage errors http://sources.gentoo.org/sys-devel/binutils/binutils-2.23.2.ebuild?r1=1.1&r2=1.2
Lovely, you've downgraded binutils which will break almost everyone's system (and has broke mine already, What exactly do we do to fix our systems with the downgraded binutils?
(In reply to comment #4) no idea wtf you're talking about. you've provided 0 real details.
What I'm saying is that after binutils was downgraded on my box, nothing would emerge. The only way to fix it was to keyword the broken version and I will have to wait for 2.23.2 to get fixed before emerging anymore packages. WTF I'm saying is that you know you cannot just downgrade binutils without breaking the toolchain. What simple way is there to fix the toolchain?
(In reply to comment #6) considering your premise is false (you can, actually, downgrade binutils just fine and have things still work), no, i have no idea wtf you're talking about. and you still have posted 0 real details.
When I did an update before, binutils was downgraded. I was just about to do a full world rebuild (usually once a month or so) and I noticed gcc would not emerge. Nor did glibc afterwards. I will try this again and see what happens.
here with the downgraded binutils, gcc doesn't emerge /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/cppopts.texi:806: @itemx must follow @item make[3]: *** [doc/cpp.info] Error 1 make[3]: *** Waiting for unfinished jobs.... /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/md.texi:1631: warning: node prev `Machine Constraints' in menu `Disable Insn Alternatives' and in sectioning `Modifiers' differ /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/md.texi:3755: warning: node next `Disable Insn Alternatives' in menu `Machine Constraints' and in sectioning `Define Constraints' differ /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/md.texi:3755: warning: node prev `Disable Insn Alternatives' in menu `Modifiers' and in sectioning `Machine Constraints' differ /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/gcc/doc/md.texi:3848: warning: node prev `Define Constraints' in menu `Machine Constraints' and in sectioning `Disable Insn Alternatives' differ make[3]: *** [doc/gccint.info] Error 1 rm gcc.pod make[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build' make: *** [bootstrap-lean] Error 2 emake failed * ERROR: sys-devel/gcc-4.7.2-r1 failed (compile phase): * emake failed with bootstrap-lean * * Call stack: * ebuild.sh, line 93: Called src_compile * environment, line 4145: Called toolchain_src_compile * environment, line 4808: Called gcc_do_make * environment, line 2444: Called die * The specific snippet of code: * emake LDFLAGS="${LDFLAGS}" STAGE1_CFLAGS="${STAGE1_CFLAGS}" LIBPATH="${LIBPATH}" BOOT_CFLAGS="${BOOT_CFLAGS}" ${GCC_MAKE_TARGET} || die "emake failed with ${GCC_MAKE_TARGET}"; * * If you need support, post the output of `emerge --info '=sys-devel/gcc-4.7.2-r1'`, * the complete build log and the output of `emerge -pqv '=sys-devel/gcc-4.7.2-r1'`. * * Please include /var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build/gcc-build-logs.tar.bz2 in your bug report * * The complete build log is located at '/var/tmp/portage/sys-devel/gcc-4.7.2-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-devel/gcc-4.7.2-r1/temp/environment'. * Working directory: '/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build' * S: '/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build' >>> Failed to emerge sys-devel/gcc-4.7.2-r1, Log file: >>> '/var/tmp/portage/sys-devel/gcc-4.7.2-r1/temp/build.log' * * The following package has failed to build or install: * * (sys-devel/gcc-4.7.2-r1::gentoo, ebuild scheduled for merge), Log file: * '/var/tmp/portage/sys-devel/gcc-4.7.2-r1/temp/build.log' * Linux1 billydv #
That isn't due to a binutils downgrade. Probably the update to texinfo 5.1 caused that (it's been a fun week).
(In reply to comment #9) as Ryan said, that has absolutely nothing to do with binutils. there is a bug open already on the topic.
My aplologies, it's an amazing coincidence that the first two packages that I tried to emerge after downgrading binutils failed, gcc and glibc, I of course assumed it was the binutils downgrade. Thanks
(In reply to comment #1) > The default changed to --no-copy-dt-needed-entries back in 2.22. Why we're > hitting it now I don't know. --no-copy-dt-needed-entries in 2.22 was buggy. http://sourceware.org/ml/binutils/2013-01/msg00085.html
Okay, so assuming that these are valid underlinking errors we should start fixing packages. Are you okay with keeping this masked?
(In reply to comment #14) that's fine. some of these packages are a little suspicious in that they use C++ features (like atomics) which implicitly pull in pthreads. a bit more discussion might have to be had for that.
Looks like we already have an active tracker for underlinking (bug #372079) so let's use that instead.
Well this is going nowhere. Time to unmask? Can you expand on the pthreads comment?
(In reply to Ryan Hill from comment #17) i think the pthreads thing is just latest 2.23.52.x.x and not 2.23.2 (see the referenced upstream bug for details). unmasking 2.23.2 should be fine as long as all the bugs we see are actually bugs in the package (seems like that's the case).
Commit message: Unmask again since we know better what is failing (the packages themselves). I built a good number of packages now using 2.23.2, so hopefully most packages should be sane and we can put pressure on the few still failing. http://sources.gentoo.org/sys-devel/binutils/binutils-2.23.2.ebuild?r1=1.2&r2=1.3
there are no more issues in the tree afaik
