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?
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.
This bug is too old to reproduce, closing it.
