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

Bug 269596

Summary: gold linker breaks prelinking: section file offsets not monotonically increasing
Product: Gentoo Linux Reporter: Alec Meyers <alecm_88>
Component: [OLD] Core systemAssignee: 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
When trying to prelink a binary built with the GOLD linker, prelink gives the following error (I'm using p7zip just as an example just because I remember building it with GOLD linker and it doesn't take long to rebuild):

# prelink -Ram |& grep p7zip
prelink: /usr/lib/p7zip/7zCon.sfx: section file offsets not monotonically increasing
prelink: /usr/lib/p7zip/7zr: section file offsets not monotonically increasing
prelink: /usr/lib/p7zip/7za: section file offsets not monotonically increasing
prelink: /usr/lib/p7zip/7z: section file offsets not monotonically increasing

After rebuilding it with GNU ld, it prelinks fine:

# prelink -vRam |& grep p7zip
Prelinking /usr/lib/p7zip/7zCon.sfx
Prelinking /usr/lib/p7zip/7zr
Prelinking /usr/lib/p7zip/7za
Prelinking /usr/lib/p7zip/7z

Reproducible: Always

Steps to Reproduce:
1. USE=gold emerge binutils
2. emerge p7zip
3. prelink -vRam |& grep p7zip
4. USE=-gold emerge 
5. emerge p7zip
6. prelink -vRam |& grep p7zip
Comment 1 Christophe Saout 2009-10-05 23:20:46 UTC
Is there an upstream bug about this?
Comment 2 SpanKY gentoo-dev 2009-10-05 23:40:46 UTC
probably not, and cant say that anyone here is going to pursue the issue.  the prelink "upstream" sucks.
Comment 3 Christophe Saout 2009-11-22 10:35:28 UTC
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)
Comment 4 SpanKY gentoo-dev 2009-11-22 17:57:00 UTC
thanks for following up
Comment 5 Petr Behan 2010-01-04 18:24:56 UTC
(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).
Comment 6 SpanKY gentoo-dev 2010-01-05 01:12:14 UTC
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.
Comment 7 Petr Behan 2010-01-07 10:03:33 UTC
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.
Comment 8 SpanKY gentoo-dev 2010-01-08 03:38:02 UTC
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
Comment 9 Lóránt Farkas 2010-05-06 09:09:06 UTC
There is a workaround at 

http://sourceware.org/bugzilla/attachment.cgi?id=4713&action=view
Comment 10 Hanno Böck gentoo-dev 2011-08-02 12:46:34 UTC
Upstream claims this is fixed:
http://sourceware.org/bugzilla/show_bug.cgi?id=11483