[lfs-dev] Two changes to consider for 8.0
john.frankish at outlook.com
Sat Dec 31 03:53:15 PST 2016
> > 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.
I've followed LFS to build a toolchain several times, except that I built gold and used isl as a dep.
With all of the toolchains, wherever other packages automatically use gold (libreoffice and others) compilation fails for different non-obvious (to me at least) reasons until gold is disabled.
> > 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.
It's perhaps more correct to say that a specific version of gcc requires a specific range of versions of isl - this being said, I have not noticed any obvious advantages of using gcc compiled against isl - it is also not obvious whether binutils needs compiling against isl (there is a configure switch for it).
More information about the lfs-dev