This is causing endless preserved-rebuild loop. Steps to reproduce: 1. install sys-libs/binutils-libs and ~sys-devel/binutils-config-5 2. # ldd /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes.so linux-vdso.so.1 (0x00007ffc8757e000) libbfd-2.25.1.so => /usr/lib64/libbfd-2.25.1.so (0x00007fd558d79000) libc.so.6 => /lib64/libc.so.6 (0x00007fd5589ce000) libz.so.1 => /lib64/libz.so.1 (0x00007fd5587b5000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fd5585b1000) /lib64/ld-linux-x86-64.so.2 (0x00007fd559477000) 3. uninstall sys-libs/binutils-libs 4. portage complains: !!! existing preserved libs: >>> package: sys-libs/binutils-libs-2.25.1-r1 * - /usr/lib64/libbfd-2.25.1.so * used by /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so (sys-devel/binutils-2.25.1-r1) Use emerge @preserved-rebuild to rebuild packages using these libraries 5. run emerge @preserved-rebuild 6. portage complains again ... and so on ...
Created attachment 415362 [details, diff] toolchain-binutils.eclass.patch Hack shamelessly stolen from fedora [1] :) After applying this patch and rebuilding binutils: $ objdump -p /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so | grep PATH RUNPATH /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1 $ ldd /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so linux-vdso.so.1 (0x00007ffc273e6000) libbfd-2.25.1.so => /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libbfd-2.25.1.so (0x00007f945764c000) libc.so.6 => /lib64/libc.so.6 (0x00007f9457269000) libz.so.1 => /lib64/libz.so.1 (0x00007f9457051000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f9456e4d000) /lib64/ld-linux-x86-64.so.2 (0x00007f9457d14000) [1] http://pkgs.fedoraproject.org/cgit/binutils.git/tree/binutils.spec
(In reply to Alexander Tsoy from comment #1) > Created attachment 415362 [details, diff] [details, diff] > toolchain-binutils.eclass.patch Hmm.. There is a comment in opcodes/Makefile.am: # It's desirable to list ../bfd/libbfd.la in DEPENDENCIES and LIBADD. # Unfortunately this causes libtool to add -L$(libdir), referring to the # planned install directory of libbfd. This can cause us to pick up an # old version of libbfd, or to pick up libbfd for the wrong architecture # if host != build. So for building with shared libraries we use a # hardcoded path to libbfd.so instead of relying on the entries in libbfd.la. And this is indeed the case: libtool: relink: x86_64-pc-linux-gnu-gcc -shared .libs/dis-buf.o .libs/disassemble.o .libs/dis-init.o .libs/i386-dis.o .libs/i386-opc.o -Wl,-rpath -Wl,/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1 -Wl,--as-needed -L/var/tmp/portage/sys-devel/binutils-2.25.1-r1/work/build/opcodes/../libiberty/pic -L/var/tmp/portage/sys-devel/binutils-2.25.1-r1/image//usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1 -L/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1 -lbfd -L/var/tmp/portage/sys-devel/binutils-2.25.1-r1/work/build/bfd/../libiberty/pic -liberty -lz -ldl -Wl,-O1 -Wl,/var/tmp/portage/sys-devel/binutils-2.25.1-r1/work/build/opcodes/../bfd/.libs/libbfd.so -Wl,-lc -Wl,--as-needed -Wl,-lm -Wl,--no-as-needed -Wl,-soname -Wl,libopcodes-2.25.1.so -o .libs/libopcodes-2.25.1.so
ignoring things like revdep-rebuild, this isn't an issue in practice: these internal libs are used only by binutils progs, and those all have rpaths to the internal paths. so it's not really possible to load libopcodes.so from the internal path but libbfd.so from the system path. if revdep-rebuild is unhappy though, we probably should try to rectify that.
I had this issue as well on a fresh ~amd64 installation. Thanks to Alexander it is now fixed.
This also breaks prelinking on x86_64, even with binutils-libs never having been installed and only a single binutils present ont he system. To verify, emerge binutils-config-5-5-r2 and binutils-2.25.1-r2 (in that order) # prelink -am prelink: /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so: Could not find one of the dependencies # ldd /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so linux-vdso.so.1 (0x00007ffd9c59a000) libbfd-2.25.1.so => not found libc.so.6 => /lib64/libc.so.6 (0x00007f153c27d000) /lib64/ld-linux-x86-64.so.2 (0x000055c7de0b7000) If masking =binutils-config-5-r2 and emerging binutils-config and binutils again (in that order), everything is fine. # prelink -am (no errors) # ldd /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so linux-vdso.so.1 (0x00007ffdc17f0000) libbfd-2.25.1.so => /usr/x86_64-pc-linux-gnu/lib/libbfd-2.25.1.so (0x0000003000c00000) libc.so.6 => /lib64/libc.so.6 (0x0000003000400000) libz.so.1 => /lib64/libz.so.1 (0x0000003001400000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003000800000) /lib64/ld-linux-x86-64.so.2 (0x000055d5055ed000) Could binutils-config-5 be ~amd64 until this is resolved? I see that people might want it, in which case they can keyword it, but the default causes breakages.
(In reply to ahagen from comment #5) prelink is dead, and there's 0 chance of moving binutils-config back to ~arch because of it
Should prelink then maybe be treecleaned then? In that case, was its functionality replaced by something? (I am using it for years... ;) Thanks
*** Bug 579978 has been marked as a duplicate of this bug. ***
(In reply to Pacho Ramos from comment #7) this issue is unrelated to prelink, and things are a bit more nuanced now that bug 575586 has landed. i would expand: (1) there's a new upstream, so the prelink project isn't as dead as i said previously. (2) prelink does not work w/ASLR or w/PIE. if you are using either, prelink makes no sense and is a waste of time.
*** Bug 578486 has been marked as a duplicate of this bug. ***
*** Bug 586108 has been marked as a duplicate of this bug. ***
i had meant to include this in 2.26.1, but that got pushed out before it was done it's in the 2.27 patchset now. let's see how well it works.
*** Bug 600588 has been marked as a duplicate of this bug. ***
*** Bug 601848 has been marked as a duplicate of this bug. ***
*** Bug 606446 has been marked as a duplicate of this bug. ***
*** Bug 607246 has been marked as a duplicate of this bug. ***
I don't think this is fixed. See https://bugs.gentoo.org/show_bug.cgi?id=607246.
*** Bug 612598 has been marked as a duplicate of this bug. ***
*** Bug 612762 has been marked as a duplicate of this bug. ***
*** Bug 612788 has been marked as a duplicate of this bug. ***
*** Bug 613226 has been marked as a duplicate of this bug. ***
*** Bug 613310 has been marked as a duplicate of this bug. ***
Although sent here as a duplicate and showing solved it is not that obvious.. solution is: emerge --depclean -a and remove the binutils old package, then a emerge @preserved-rebuild may be needed to fix the dangling issues from the removal.
*** Bug 615168 has been marked as a duplicate of this bug. ***