Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 563934 - sys-devel/binutils: libopcodes.so lacks RPATH to local libbfd.so which makes revdep-rebuild unhappy
Summary: sys-devel/binutils: libopcodes.so lacks RPATH to local libbfd.so which makes ...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 578486 579978 586108 600588 601848 606446 607246 612598 612762 612788 613226 613310 615168 (view as bug list)
Depends on:
Blocks: 564174
  Show dependency tree
 
Reported: 2015-10-24 08:10 UTC by Alexander Tsoy
Modified: 2017-04-10 17:11 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
toolchain-binutils.eclass.patch (toolchain-binutils.eclass.patch,396 bytes, patch)
2015-10-24 14:21 UTC, Alexander Tsoy
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Tsoy 2015-10-24 08:10:17 UTC
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 ...
Comment 1 Alexander Tsoy 2015-10-24 14:21:32 UTC
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
Comment 2 Alexander Tsoy 2015-10-25 19:58:50 UTC
(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
Comment 3 SpanKY gentoo-dev 2015-11-23 10:52:47 UTC
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.
Comment 4 Coacher 2015-12-29 05:36:48 UTC
I had this issue as well on a fresh ~amd64 installation. Thanks to Alexander it is now fixed.
Comment 5 Arth 2016-03-23 12:41:27 UTC
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.
Comment 6 SpanKY gentoo-dev 2016-03-23 16:12:46 UTC
(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
Comment 7 Pacho Ramos gentoo-dev 2016-04-02 12:05:54 UTC
Should prelink then maybe be treecleaned then? In that case, was its functionality replaced by something? (I am using it for years... ;)

Thanks
Comment 8 SpanKY gentoo-dev 2016-04-19 18:09:50 UTC
*** Bug 579978 has been marked as a duplicate of this bug. ***
Comment 9 SpanKY gentoo-dev 2016-04-19 18:13:05 UTC
(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.
Comment 10 SpanKY gentoo-dev 2016-05-11 05:35:24 UTC
*** Bug 578486 has been marked as a duplicate of this bug. ***
Comment 11 SpanKY gentoo-dev 2016-06-16 15:11:43 UTC
*** Bug 586108 has been marked as a duplicate of this bug. ***
Comment 12 SpanKY gentoo-dev 2016-11-15 14:49:44 UTC
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.
Comment 13 SpanKY gentoo-dev 2016-11-26 21:57:31 UTC
*** Bug 600588 has been marked as a duplicate of this bug. ***
Comment 14 SpanKY gentoo-dev 2016-12-07 03:59:02 UTC
*** Bug 601848 has been marked as a duplicate of this bug. ***
Comment 15 SpanKY gentoo-dev 2017-01-19 04:49:54 UTC
*** Bug 606446 has been marked as a duplicate of this bug. ***
Comment 16 Coacher 2017-01-28 08:54:12 UTC
*** Bug 607246 has been marked as a duplicate of this bug. ***
Comment 17 Dave Kennedy 2017-01-29 20:35:20 UTC
I don't think this is fixed. See https://bugs.gentoo.org/show_bug.cgi?id=607246.
Comment 18 SpanKY gentoo-dev 2017-02-09 15:08:23 UTC
*** Bug 606446 has been marked as a duplicate of this bug. ***
Comment 19 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2017-03-14 11:33:41 UTC
*** Bug 612598 has been marked as a duplicate of this bug. ***
Comment 20 SpanKY gentoo-dev 2017-03-15 19:09:45 UTC
*** Bug 612762 has been marked as a duplicate of this bug. ***
Comment 21 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2017-03-16 08:40:09 UTC
*** Bug 612788 has been marked as a duplicate of this bug. ***
Comment 22 Coacher 2017-03-17 17:22:16 UTC
*** Bug 612788 has been marked as a duplicate of this bug. ***
Comment 23 Coacher 2017-03-19 15:03:05 UTC
*** Bug 613226 has been marked as a duplicate of this bug. ***
Comment 24 Brian Evans (RETIRED) gentoo-dev 2017-03-20 13:41:09 UTC
*** Bug 613310 has been marked as a duplicate of this bug. ***
Comment 25 Nico Baggus 2017-03-21 22:06:17 UTC
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.
Comment 26 Brian Evans (RETIRED) gentoo-dev 2017-04-10 13:50:45 UTC
*** Bug 615168 has been marked as a duplicate of this bug. ***