Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 430812

Summary: app-portage/gentoolkit - after recent binutils upgrade, revdep-rebuild did not catch libbfd-2.21.1.so absence
Product: Portage Development Reporter: Paul Osmialowski <newchief>
Component: ToolsAssignee: Portage Tools Team <tools-portage>
Status: RESOLVED OBSOLETE    
Severity: normal CC: adaptee
Priority: Normal    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Paul Osmialowski 2012-08-10 17:26:57 UTC
After recent binutils upgrade certain number of programs stopped to work. It turned out that revdep-rebuild that I'm running after each upgrade did not catch problems caused by absence of libbfd-2.21.1.so (from previous binutils version).
I was able to fix this problem by calling revdep-rebuild -L libbfd-2.21.1.so - four packages were rebuilt then: dev-lang/ocaml:0 dev-util/oprofile:0 net-p2p/amule:0 x11-libs/cairo:0 - all these things started to work properly after that. This bug leads to dangerous implications - I found this problem accidently and I pinned this to binutils libraries - what about any other shared library that soon will be updated to never version? Will revdep-rebuild be able to find depending software packages that should be rebuilt?



I wonder if revdep-rebuild could be fooled by cross-avr/binutils libraries (I'm doing experiments with arduino) - it is sitll versioned 2.21.1-r1 and provides /usr/lib/binutils/avr/2.21.1/libbfd-2.21.1.so which is actually recognised as x86 binary:

file /usr/lib/binutils/avr/2.21.1/libbfd-2.21.1.so
/usr/lib/binutils/avr/2.21.1/libbfd-2.21.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

unfortunately, /usr/lib/binutils/avr/2.21.1 is not listed in LD_LIBRARY_PATH, so how revdep-rebuild could use it to solve dynamic linking for affected software packages?
Comment 1 Paul Varner (RETIRED) gentoo-dev 2012-08-22 19:36:59 UTC
revdep-rebuild builds its own LD_LIBRARY_PATH, so you are probably correct on what caused the problem.  There is an option "--no-ld-path" which will tell revdep-rebuild to not create its own path.  However, using this flag can result in false positives which is why it is not on by default.
Comment 2 Paul Osmialowski 2018-11-27 07:16:39 UTC
This bug is too old to reproduce, closing it.