Summary: | gold linker breaks prelinking: section file offsets not monotonically increasing | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alec Meyers <alecm_88> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | christophe, esigra |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 269315 |
Description
Alec Meyers
2009-05-12 17:39:11 UTC
Is there an upstream bug about this? probably not, and cant say that anyone here is going to pursue the issue. the prelink "upstream" sucks. The version of gold bundled with binutils-2.20.51.0.3 (not yet in tree) resolves all prelink issues for me. Also a couple of other issues, like unresolved symbols with not explicit link dependencies. (in fact I managed to compile my whole system now with gold and prelink everything without errors) thanks for following up (In reply to comment #3) > The version of gold bundled with binutils-2.20.51.0.3 (not yet in tree) > resolves all prelink issues for me. Also a couple of other issues, like > unresolved symbols with not explicit link dependencies. (in fact I managed to > compile my whole system now with gold and prelink everything without errors) > Sorry for bug necromancy, but the "fix" is not fix at all. >sys-devel/binutils-2.20 (in portage tree) just disables gold as default linker: /usr/x86_64-pc-linux-gnu/binutils-bin/2.20/ld is hardlink to ld.bfd, ld.gold sits there as standalone binary. I found no easy way to force gcc to use gold under this configuration. Other than using EXTRA_ECONF="--enable-gold=yes" - or manually change the hardlink. And I'd discourage doing either, in addition to NOT fixing problem with prelink or non-explicit link dependencies, 2.20.51.0.4 also has broken support for --as-needed (even more broken than 2.20, where it is just ignored), with upstream bug filed for it already (http://sourceware.org/bugzilla/show_bug.cgi?id=11042). If someone with enough rights will read this, I'd vote for reopening this bug and leave it as source of information for other people, at least until seriously considering enabling gold as supported option (imho not likely in near future, so far I know about 34 packages broken by the explicit link dependencies issue, few other just plain refuse to build with gold in configure script or fail due to unsupported options... and kernel behaves weird for me, though I can't yet prove it's due to gold). if you want to play with gold, you should use the latest version of binutils in the tree. we arent going to waste time back porting gold-specific changes to stable/unstable versions. I may have been too verbose and unclear what it think is wrong... I have this tendency to overexplain myself with needless details. I am aware that gold is here mainly to play with and I can't expect it to "just work" or that you will backport anything to it. That's why it has is't own tracker meta bug - to see what is still broken and if it's ready for serious work. I just seems wrong that resolution to this bug is _FIXED_, when the fix is effectively "upgrade to binutils that does not really enable gold even with +gold". The bug itself remains, and it will be back when newer version of binutils start to enable it for real again, or when the ebuild is fixed to provide correct hadlink with +gold USE (or maybe some magic with eselect, or some other documented way to enable it). Again, I'm not asking here that you go and fix this (it affects only without-keywords-masked version of binutils that can be expected to behave strange). It's just that any other resolution would be closer to reality - UPSTREAM, WONTFIX, ... or leave it open until it's reasonable to decide if a real fix is possible at all. To document another unresolved issue that blocks the tracker bug. sorry, i guess i misread your first post. what you say makes sense. feel free to investigate & post upstream ... i dont have much (->any) time atm to investigate prelink+gold There is a workaround at http://sourceware.org/bugzilla/attachment.cgi?id=4713&action=view Upstream claims this is fixed: http://sourceware.org/bugzilla/show_bug.cgi?id=11483 |