Summary: | sys-devel/binutils-2.25.1-r1: various packages fail with: .../x86_64-pc-linux-gnu/bin/ld: undefined symbol: elf32xtensa_size_opt | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ahferroin7, alexander, beolach+gb, bertrand, bruce, dschridde+gentoobugs, gnustep, ikelos, jer, jj, josef64, mbartoszkiewicz, mgorny, pcmoore, qa, toolchain, vityokster |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=562566 https://bugs.gentoo.org/show_bug.cgi?id=563384 https://bugs.gentoo.org/show_bug.cgi?id=573868 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 564174 | ||
Attachments: |
emerge-history.txt
sci-mathematics:flint-2.4.5:20151002-024855.log |
Description
Toralf Förster
2015-10-02 16:52:23 UTC
Created attachment 413528 [details]
emerge-history.txt
Created attachment 413530 [details]
sci-mathematics:flint-2.4.5:20151002-024855.log
Seeing same issue in dev-ruby/ruby-glib2-2.2.5 in its configure phase, mkmf.log. Potentially caused by binutils 2.25.1-r1? Reverting to binutils 2.25-r1 works around this problem. Adding binutils herd. *** Bug 562680 has been marked as a duplicate of this bug. *** builds fine for me w/2.25.1 go into the build dir and try running `make` and see if it still fails (In reply to SpanKY from comment #6) > builds fine for me w/2.25.1 > > go into the build dir and try running `make` and see if it still fails woot. That does not fail. But "emerge ..." and "ebuild ... compile" failes, and this chroot image does have sys-devel/binutils-2.25.1-r1 But OTOH ther's something wrong with nurses or so at that chroot image ... *** Bug 562566 has been marked as a duplicate of this bug. *** *** Bug 562402 has been marked as a duplicate of this bug. *** Possibly related: bug #563604 *** Bug 563384 has been marked as a duplicate of this bug. *** *** Bug 563604 has been marked as a duplicate of this bug. *** I have the same problem (with dev-ruby/racc). It appears I have two different versions of libbfd-2.25.1.so: # ls -l /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so /usr/lib/libbfd-2.25.1.so -rwxr-xr-x 1 root root 8077224 08-28 21:20 /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so -rwxr-xr-x 1 root root 1211072 10-05 22:04 /usr/lib/libbfd-2.25.1.so # qfile /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so /usr/lib/libbfd-2.25.1.so sys-devel/binutils (/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so) sys-libs/binutils-libs (/usr/lib64/libbfd-2.25.1.so) # nm -AD /usr/lib/libbfd-2.25.1.so /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so | grep elf32xtensa_size_opt /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so:00000000009bdf10 B elf32xtensa_size_opt I think something the ruby build system does (maybe setting LD_LIBRARY_PATH?) makes it select the wrong one -- but the real problem is, why are there two? # ld ld: no input files # LD_LIBRARY_PATH=/usr/lib ld ld: symbol lookup error: ld: undefined symbol: elf32xtensa_size_opt # ldd =ld linux-vdso.so.1 (0x00007ffc3f0be000) libbfd-2.25.1.so => /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so (0x00007f874cfe5000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f874cde1000) libc.so.6 => /lib64/libc.so.6 (0x00007f874ca45000) libz.so.1 => /lib64/libz.so.1 (0x00007f874c82f000) /lib64/ld-linux-x86-64.so.2 (0x00007f874d9a4000) # LD_LIBRARY_PATH=/usr/lib ldd =ld linux-vdso.so.1 (0x00007ffe87b89000) libbfd-2.25.1.so => /usr/lib/libbfd-2.25.1.so (0x00007fba6de2f000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fba6dc2b000) libc.so.6 => /lib64/libc.so.6 (0x00007fba6d88f000) libz.so.1 => /lib64/libz.so.1 (0x00007fba6d679000) /lib64/ld-linux-x86-64.so.2 (0x00007fba6e15b000) (In reply to mbartoszkiewicz@gmail.com from comment #13) > # ls -l /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so > /usr/lib/libbfd-2.25.1.so > -rwxr-xr-x 1 root root 8077224 08-28 21:20 > /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so So this is only reproducible with USE=multitarget I cannot reproduce this bug with sci-mathematics/flint and dev-libs/xalan-c. No idea what's wrong with them. mkmf from ruby-2.1 (>=2.1?) is indeed setting LD_LIBRARY_PATH variable. dev-ruby/racc (and presumably all other ruby extensions written in C) can be fixed by the following ruby patch: https://github.com/chef/omnibus-software/blob/master/config/patches/ruby/ruby-2_1_3-no-mkmf.patch app-text/hyperestraier is also setting LD_LIBRARY_PATH: # grep LD_LIBRARY_PATH /var/tmp/portage/app-text/hyperestraier-1.4.13/work/hyperestraier-1.4.13/configure.in LD_LIBRARY_PATH="$HOME/lib:/usr/local/lib:$LD_LIBRARY_PATH" export PATH LIBRARY_PATH LD_LIBRARY_PATH CPATH PKG_CONFIG_PATH LD_LIBRARY_PATH="$LD_LIBRARY_PATH:`pkg-config --variable=libdir qdbm`" export PATH LIBRARY_PATH LD_LIBRARY_PATH CPATH PKG_CONFIG_PATH # pkg-config --variable=libdir qdbm /usr/lib64 But fixing individual packages is a lot of pain. Building binutils with --disable-shared seems also not an option - it increases package size almost twice. With USE=multitarget it becomes >250Mb in size: # qsize 'sys-devel/binutils-2' sys-devel/binutils-2.25.1-r1: 3 041 files, 33 non-files, 265 017,424 KiB I tested it today again at 3 fresh chroot images, 1 with xalan-c, 2 other w/o xalan-c installed - works so far. So I'll close this now as worksforme, ok ? (In reply to Alexander Tsoy from comment #16) build systems shouldn't be setting LD_LIBRARY_PATH. if you find one that is, that package is broken. is this only showing up on those packages ? (In reply to SpanKY from comment #18) > is this only showing up on those packages ? Currently this issue is reported for 5 packages. I can only reproduce it with 2 packages: dev-ruby/racc (actually caused by mkmf from >=ruby-2.1) app-text/hyperestraier (bug #562566) And one is failing on my test VM for another reason (bug #555670): app-shells/ksh (but looking on its build system, it seems indeed playing with LD_LIBRARY_PATH) I suspect that not many people build binutils with USE=multitarget, so the above list is far from being complete. (In reply to Alexander Tsoy from comment #19) > dev-ruby/racc (actually caused by mkmf from >=ruby-2.1) Bug with the same root cause: bug 560626 (and probably all of its duplicates). I think we should open separate bug for dev-lang/ruby and make all dev-ruby/* bugs a duplicate of it. (In reply to Alexander Tsoy from comment #20) > Bug with the same root cause: bug 560626 Oops. I mean bug #561902 (In reply to Alexander Tsoy from comment #20) > I think we should open separate bug for dev-lang/ruby and make > all dev-ruby/* bugs a duplicate of it. I filed bug #564272 Confirming & voting. I have two systems that have the following packages affected by this: =dev-ruby/racc-1.4.13 =dev-ruby/rrdtool-bindings-1.5.4 =dev-vcs/subversion-1.9.2 Reverting to =sys-devel/binutils-2.25 gets them installed. /Charlie Add gnustep-base/gnustep-base to the list of failing packages. Also, I've found that disabling USE='multitarget' resolves the issue on the problematic versions of binutils. (In reply to Austin S. Hemmelgarn from comment #24) > Add gnustep-base/gnustep-base to the list of failing packages. > > Also, I've found that disabling USE='multitarget' resolves the issue on the > problematic versions of binutils. I forgot to mention, bug 502308 is a duplicate of this one (same issue, just against gnustep-base/gnustep-base (In reply to Austin S. Hemmelgarn from comment #25) > (In reply to Austin S. Hemmelgarn from comment #24) > > Add gnustep-base/gnustep-base to the list of failing packages. > > > > Also, I've found that disabling USE='multitarget' resolves the issue on the > > problematic versions of binutils. > > I forgot to mention, bug 502308 is a duplicate of this one (same issue, just > against gnustep-base/gnustep-base Woops, mistyped, I meant bug 562308. *** Bug 562308 has been marked as a duplicate of this bug. *** With sys-devel/binutils-2.25.1-r1[multitarget], gnustep-base/gnustep-make fails in configure steps (see #562308 for detailed config.log): configure:3788: checking for C compiler default output file name configure:3810: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -I/usr/local/include -I/usr/local/include -I/usr/include -Wl,-O1 -Wl,--as-needed -L/usr/local/lib64 -L/usr/local/lib64 -L/usr/lib64 conftest.c >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: symbol lookup error: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: undefined symbol: elf32xtensa_size_opt Successfully killed a lot of time with ruby ffi gem until find this bug.. Is someone going to do anything about this? This is a serious regression in stable tree, causing a number of known build failures, which in turn have gotten to the point of making it impossible to upgrade a fair number of systems. (In reply to Michał Górny from comment #30) > This is a serious regression in stable tree binutils-config-5 and binutils-libs are not stable (In reply to Alexander Tsoy from comment #31) > (In reply to Michał Górny from comment #30) > > This is a serious regression in stable tree > > binutils-config-5 and binutils-libs are not stable The issue appears to be in the stable version of sys-devel/binutils, which depends on neither of binutils-config or binutils-libs. Unless you have hard evidence to the contrary, then it's a regression in stable because the affected version of sys-devel/binutils is marked stable. (In reply to Austin S. Hemmelgarn from comment #32) Read this bug from comment #13 please. (In reply to Alexander Tsoy from comment #33) > (In reply to Austin S. Hemmelgarn from comment #32) > > Read this bug from comment #13 please. Apologies, I had missed that somehow. (In reply to Alexander Tsoy from comment #16) i've re-opened bug 563384 for tracking ruby. i don't use ruby anywhere so i don't notice misbehavior on that side. we currently use DT_RUNPATH everywhere in Gentoo as it allows LD_LIBRARY_PATH to override library lookups. could force binutils to use old dtags (DT_RPATH) which gives precedence over LD_LIBRARY_PATH, but let's see how these bugs go first. sci-mathematics/flint-2.5.2 fails for me, with binutils 2.25.1-r1 and gcc 5.3.0. Interestingly, when I manually cd to the portage build folder and run the exact same linking command that ebuild just tried to run and which failed, it succeeds. (In reply to Jonas Jelten from comment #36) file a new bug for flint please i think we've tracked down all the latent issues here, and it wasn't really a bug in binutils itself |