After binutils update, revdep-rebuild catches problem with cairo. Maybe we need := into cairo ebuilds
This is a bit special case as it's due binutils-config running -> bug 459038
I have never experienced this issue. Are you using clang? What USE flags do you have on cairo (and which version of cairo)?
I've experienced it a few times, always with gcc. The cause is libcairo-trace.so, which links against libbfd from binutils. I don't know much more.
Also binutils is missing in deps: $ check-deps.sh cairo * Checking "x11-libs/cairo-1.12.18-r1" * Missing in RDEPEND and DEPEND: sys-devel/binutils X86_64;libbfd-2.24.so /usr/lib64/cairo/libcairo-trace.so.0.0.0 'qgrep -N sys-devel/binutils' indicates that a lot packages have it in deps, please add it to cairo too.
It happened another time with the last binutils update. Are you able to reproduce it? which info do you need?
This also affects grive: * Checking dynamic linking consistency [ 14% ] * broken /usr/bin/grive (requires libbfd-2.24.so) [ 44% ] * broken /usr/lib64/cairo/libcairo-trace.so.0.0.0 (requires libbfd-2.24.so) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages @toolchain, how are we expected to deal with this? In summary, when binutils gets updated, some tools are broken without either preserved-rebuilds or automatic rebuilds being triggered by subslots. Should binutils:0 start setting a subslot and reverse deps starting to RDEPEND on binutils:0= ?
i don't think any dep on binutils is going to work. we've long allowed people to install multiple versions and switch them on the fly. portage can't pin to a specific binutils version unless it queries for the active version (and even then it's not a 100% guarantee since you can pass custom toolchain settings via env vars). probably the only way for packages to depend on binutils libs would be to decouple the libraries linked against from the ones binutils uses internally. binutils would no longer mess with the shared library path, and we'd have a new package (binutils-libs?) that'd install the bfd/iberty/opcodes libraries and headers, and that'd be SLOT-ed for packages to depend on. binutils programs already have rpaths set on their own programs, so removing their internal libs from the system search should be fine. if it weren't, you couldn't execute an older version with a newer one active today.
binutils-libs is now in the tree. you should be able to update packages to depend on it (including subslot) now. new package: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4c2963c4795822d443a0128e5ec47d1418f6b2a1 update binutils-config & gdb to handle it: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b851bfe6001dc7abd01ab28d6b569f51c85b3c5e http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=21049b7dd9e07fc5320d8e28348d8e1b46dc5bc5
Guys, please make binutils optional dep. My system works perfectly with cairo and without binutils.
(In reply to PV from comment #9) i doubt that's true when binutils is required to compile/link code
On Darwin we use non-binutils to link, so we need to exclude the dep there too.
(In reply to Fabian Groffen from comment #11) the linker used is orthogonal to the libs linked. binutils-libs will be the latest version in normal Linux systems, even if you are using older versions of binutils to link. the programs (cairo/mysql/whatever) will use the binutils-libs at runtime.
(In reply to SpanKY from comment #12) > the programs (cairo/mysql/whatever) will use the > binutils-libs at runtime. Ok, binutils-libs indeed compiles and installs on darwin. Will test and keyword.
