> > 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). -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
