[lfs-dev] Two changes to consider for 8.0

DJ Lucas dj at linuxfromscratch.org
Sat Dec 31 02:55:47 PST 2016

On 12/30/2016 09:01 PM, Bruce Dubbs wrote:

> I don't have a problem with adding gold as you propose, but I do wonder
> what the benefits are for using it.  As best I can tell, it would only
> be useful in speeding up the link phase for some large projects.  Is
> that right?
> If so, what are some performance improvements we can expect to see?

Correct. Ken, might be able to provide some insight as to differences. 
As I go through this build, I plan to do some 1:1 comparisons for larger 
packages to see how much of difference to expect. Off the cuff, I see 
Firefox, Chromium, Webkit, and KF5 as targets for potential "wow" 
numbers. The results, however, are not relevant to the question of 
whether to include it IMO.

This one comes down to which is more costly, an extra build of bison in 
chapter 5 and additional time and build size -- which are not 
insignificant numbers -- or adding binutils to BLFS to complete the 
binutils installation if gold is desired. I'm also kind of waiting for 
2.28 so we can avoid covering the broken tests and likely reduce some of 
that time. It needs to be tested in real use with BLFS to make sure 
nothing breaks in the default configuration, so I'm getting the ball 
rolling again now while I'm doing a complete rebuild anyway, and we are 
not yet preparing for release.

> As far as ISL goes, what apps would use it?  Is the performance
> improvement significant?  I suppose there is a reason gcc doesn't
> build/install it by default.

The reason is that it is an external dependency, same as MPC, MPFR, and 
GMP (and the rest of the toolchain + GDB for that matter) which are also 
supported by the top-level autotools. It was excluded originally because 
it was an experimental feature and getting cloog, ppl, and cloog-ppl to 
play nicely in chroot required a bit of hacking, but that was several 
years ago, gcc-4.8 IIRC. The feature is now mature requiring only one 
additional library. I honestly don't know about the performance 
improvements. I haven't found any packages that will use the five 
additional optimizations by default, but I haven't really looked all 
that hard either, and again, I don't consider the results relevant to 
the discussion of including it in the book.

The other options for addressing the additional dependency are to 
install the library before GCC, or just address this in BLFS, but I 
don't know of any other consumers (besides polly - same optimizations 
for clang). In my mind, this directly affects the C and C++ drivers, so 
it should go into LFS if possible. We already have GMP in LFS (the other 
Graphite dep), but GCC uses a specific version of libisl and that needs 
to be accounted for, hence the suggestion to use the inline build 
(taking a cue from Arch) rather than it being its own package.


More information about the lfs-dev mailing list