Could this be made USE conditional please? Not everyone needs this feature, and it uses some additional diskspace, namely two files under /usr/lib/debug/.build-id/, which may account for up to 8 KiB for every binary.
Actually, it would also be nice to know what the rationale behind enabling this flag is. After all, it's spamming everyone's filesystem.
I'm too am curious. Its an interesting feature but I wonder what we would use it for and whether or not, as ulm says, it can't be made conditional on a USE flag.
So bug 491452 shows that this will lead to file collisions in /usr/lib/debug/.build-id/. I suggest that commits 1.636 and 1.640 in toolchain.eclass are reverted. Alternatively, the feature should be strictly opt-in.
(In reply to Ulrich Müller from comment #3) > So bug 491452 shows that this will lead to file collisions in > /usr/lib/debug/.build-id/. > > I suggest that commits 1.636 and 1.640 in toolchain.eclass are reverted. > Alternatively, the feature should be strictly opt-in. This is blocking the emerge of dev-lang/perl (bug 526930). (and yes in this case the existence of identical binaries in different places can well be expected. It's not ideal and can be avoided, but it should definitely not lead to a file collision and a failed emerge.) Can we please get it reverted asap?
(In reply to Andreas K. Hüttel from comment #4) > > I suggest that commits 1.636 and 1.640 in toolchain.eclass are reverted. > > This is blocking the emerge of dev-lang/perl (bug 526930). > [...] > Can we please get it reverted asap? [QA] For now, I've commented the code from above revisions, because there is no response from maintainers, and this causes file collisions for several packages. Affected users should rebuild their gcc, or, as a workaround, add the following line to their make.conf: LDFLAGS="${LDFLAGS} -Wl,--build-id=none"
*** Bug 533074 has been marked as a duplicate of this bug. ***
This is probably going to bite more and more people the more time it is around as it overlaps with the stabilization of sys-devel/gcc-4.8.3 In my case, it blocked the security update of www-client/firefox. Personally I'd recommend revbumping it to force a rebuild the next time stable systems are upgraded.
(In reply to Ulrich Müller from comment #5) > (In reply to Andreas K. Hüttel from comment #4) > > > I suggest that commits 1.636 and 1.640 in toolchain.eclass are reverted. > > > > This is blocking the emerge of dev-lang/perl (bug 526930). > > [...] > > Can we please get it reverted asap? > > [QA] For now, I've commented the code from above revisions, because there is > no response from maintainers, and this causes file collisions for several > packages. > > Affected users should rebuild their gcc, or, as a workaround, add the > following line to their make.conf: > > LDFLAGS="${LDFLAGS} -Wl,--build-id=none" This was commented out as stated above. By now everyone should have rebuilt his gcc.
Some tools, like dev-util/perf require build ids to be present to use some of its features, for example SDT, which allows to create probes on statically defined probepoints that dtrace and systemtap support: # perf test -v sdt 47: Test SDT event probing : --- start --- test child forked, pid 15293 Failed to read build id of /usr/bin/perf test child finished with -1 ---- end ---- Test SDT event probing: FAILED! I was able to work this around by appending -Wl,--build-id to CFLAGS and CXXFLAGS. This doesn't feel like a proper solution -- it doesn't generate build ids for libraries, while other distros support this for both binaries and libraries. Maybe it's worth to reenable this conditionally, under some USE flag?
Another possibility, which also seems to work, is to generate build ids, but remove usr/lib/debug/.build-id from the image before merging. I tested this with gdb and perf -- both of them work fine.
