[lfs-dev] gold

DJ Lucas blfs-dev at lucasit.com
Mon Feb 6 17:28:24 PST 2017



On 02/04/2017 10:58 AM, Ken Moffat wrote:
> On Sat, Feb 04, 2017 at 12:07:55AM -0600, DJ Lucas wrote:
>>
>> Interesting, I had just suggested to Bruce (the other day on IRC) that we go ahead and do it. I've seen absolutely no failures with bfd as the default linker with both big DEs installed. I haven't gotten around to newer QT yet. I was hoping we'd see a 2.28 release well before now. Does QT pick up gold by default?
>>
> It seems not - I have both ld.gold, ld.bfd and ldd (bfd) in /usr/bin,
> with a /usr/bin/gold directory containing an ld symlink.  I normally
> put that first on the PATH, but using a normal PATH it used ld.bfd.
>

I'm still of the mind to provide everything that the package can provide 
with two caveats. 1. We aren't increasing dependencies drastically. 2. 
No harm comes from the change. This even at the expense of a couple of 
SBU -- 0.1 for bison in Ch5 and ~3 for the gold test suite IIRC -- and 
regardless of any perceived benefit. I might be in the minority here, so 
opinions are welcome (not sure if Ken's are fully expressed above).

On the flip, nothing prevents us from burring the two additional 
switches in the wiki if there are strong feelings the other way. While I 
think a *drastic* speed/size benefit has been sufficiently debunked 
(even if only with anecdotal evidence), that doesn't render it useless. 
Samba was a good example where the maintainers were tracking down issues 
in their code that bfd managed to gloss over.

As to usability, in the default configuration, you can use -fuse-gold to 
CFLAGS/CXXFLAGS if you want to use it explicitly, but otherwise, as far 
as I have been able to tell, it is ignored unless the package maintainer 
explicitly checks for it (and presumably, the maintainer knows whether 
their dependent libraries are correct or if they still depend on bfd's 
DL-like workarounds).

With 2.27, however, the test suite is, um...messy, with a completely 
different testing framework. 2.28 will hopefully be out the door before 
package freeze, but I'd like to wait and see what things look like at 
its release.

Some interesting linker optimizations coming down the pipe as well, this 
one https://sourceware.org/ml/binutils/2017-02/msg00032.html for 
instance has piqued my interest. That is a 3.97% reduction in size. Now 
granted, that's a really big executable, and not anywhere near typical.

--DJ



More information about the lfs-dev mailing list