This one really got me. When it first failed I thought it was because of lto, so I put no-lto in package.env and tried again. Then I found out it was because of gold, and simply added linker-bfd. It failed even earlier (in configure) with this:

Code:

Checking for custom code : Could not find the python development headers

Then I removed no-lto (leaving only linker-bfd) and it worked. Don't know what's going on here.

is run on my update script and result is mail to me.
Quite rudimentary, but...

@CaptainBlood Maybe enable-lto got misplaced in 5.2.3.3-r1. I am on 5.2.4.2 and doxygen is not installed in my system. Child_of_Sun_24 suggestion is exactly what I've done to get rid of libreoffice ebuild need in local overlay. It is frustratting to remember in the middle of the long emerge "Oh! I forgot about lto..."

Code:

Filename: /etc/portage/env/app-office/libreoffice with the following content:
EXTRA_ECONF="--enable-lto"

@saboya
I am not using gold. I tried it multiple times and found to be unreliable for system-wide. Put it in the "box" with icc, llvm. Maybe in the future things will go better.

As altblitz mentioned two pages ago, chromium is compiling with lto using --param lto-partitions=1, but with the cost of compile time increase:

System wide instability with Gold? I've been using it for a year or so now with no issues except compiling problems. You're getting runtime problems with Gold? What kinds???

As for LTO kernel development, I'm in the middle of moving right now, there's a lot of kernel development I've been meaning to catch up on, backporting all the latest and greatest security features of 4.8 and 4.9 - vmapped stacks, hardened usercopy, etc etc. also splitting up the Grsecurity patch into separate files for easier maintainability and dissecting the enormous patch blob, might even try and join the KSPP team, kernel self protection project (if they aren't too crazy)

People have been asking about a secure kernel that you don't need to constantly update or switch releases, so with a barrage of backport patches, people can have all the same security features of 4.9 to older kernels, they'll be hosted here (empty tree right now, haven't worked on it yet)

There's a lot to do, I've just been busy so I haven't had the time. LTO (fun project) and security patches (real project) are both a priority for me right now, might be a few more weeks until I get around to it. Don't worry!

Cheers guys, and thanks for testing out that script. Please star the project if you can, it will feature a chroot/linux filesystem builder as well, also written entirely in bash, practically LFS in a script, and btw, all the LFS docs in regards to building a toolchain couldn't be further from the truth.

1.) GCC does not support newlib, I was wondering why it wasn't building, GCC bug report I filed confirmed this.

2.) GMP, MPC, and MPFR are not extracted in the GCC builds in the LFS docs, so you get decimal float errors (IIRC)

3.) LFS does not install GLIBC headers before GCC, so GCC does not build

4.) Configure lines are all goofy

5.) Unncessesary modifications to source trees

Tons and tons of issues I can't even remember them all with LFS, but it's a complete mess so I'm basically re-doing LFS entirely and converting it all in a script because those guys can't build a Linux system to save their life, the order is all goofed up on the build process and countless steps are missing. The crosstool-ng tree is in much better shape.

FWIW I just noticed gcc-6.3.0 with gold linker produces an error in kernel compiling. Just happened to look at the screen when I saw it, compiling didn't stop. Not good._________________Please learn how to denote units correctly!

I'm not a linker specialist, much less kernel specialist, so I couldn't argue with you if this is a binutils or kernel bug. But justbecause it can be worked around in either means the problem is in the other end.

Since the patch I mentioned already made it into upstream, I would guess they realize it's incorrect nad have to fix it anyway.

Several packages succeeded which failed previously, most remarkably most qt packages (though not all).

On the other hand, the link caused additional failures: Packages failing with

Quote:

libtool: eval: line ...: syntax error near unexpected token `|'

(those marked in the list with "|") could previously usually be fixed with -ffat-lto-objects; now they always require to switch off -flto completely. Some other packages even exhibit this or other errors now even though they work without the symlink.

Some runtime errors have vanished due to the symlink. For instance, qpdfview now runs fine instead of complaining about nonreadable plugins.

On the other hand, serious runtime errors and stability issues remain or are new:

app-arch/bzip2 fails completely at runtime.
app-shells/zsh has unreproducible problems (it can compile broken .zwc files or fail to parse the command line). This did not occur without the symlink.
media-libs/mesa seems to cause firefox crashes, though this is not very reproducible and might be a strange accident.
Certainly there are more issues which I just have not found yet.

Statistics:

Not counting the packages which break only with -fwhole-program (which unsurprisingly is overly aggressive) and those which have not been emerged recently (marked in the list with "PO"), there are about

130 packages failing on x86
95 packages failing on amd64

out of a total of ~1400. If one takes into account only packages which actually compile code (excluding e.g. virtuals/* and packages which install only script, text, or data files), I would guess that about 20% of these packages fail.

I'm not a linker specialist, much less kernel specialist, so I couldn't argue with you if this is a binutils or kernel bug. But justbecause it can be worked around in either means the problem is in the other end.

Since the patch I mentioned already made it into upstream, I would guess they realize it's incorrect nad have to fix it anyway.

When i read the Bugtracker Thread it looks like that it is a binutils problem, i am not an expert, too (Posted it only because not everyone is able to backport a fix for binutils)

@NTU I will give another chance to Google Linker. I enable it on chromium compilation (via -fuse-ld=gold) but I haven't seen any improvements. Of course it could be due to lto-partition=1. When I'll have time will try with libreoffice. If it link/compile faster I'll try a world recompile with gold.
Of course, any work on kernel security or lto if always appreciated.
One more question: what exactly happened between gcc 5 and 6 regarding Gentoo old hardened patches ? Were they accepted upstream ? Where did they disappear ?

@mv First, great statistic (and effort).
Are you using a hardened profile ? That's the only profile where I got numerous runtime errors with lto. I should specify earlier that I am using default/linux/amd64/13.0/no-multilib profile. gnome-shell is the only package that exhibit runtime errors.
I was looking at yours flto failure list. As far as I understand both -flto and -fwhole-program don't work very well together and that combination is discouraged.

The reason I asked then and now about impressions and stability is no matter what benefits any compilation compilation flag may bring, stability is sacred, so please notify us there of such cases._________________Sorry for my English. I'm still learning this language.

Are you using a hardened profile? That's the only profile where I got numerous runtime errors with lto.

I am using the hardened kernel (and some hardening *FLAGS), but not by profile. However, most runtime errors I experienced were not triggered by a kernel exception (which would happen if it is a problem of reallocating in a readonly section), so I doubt that this is special to hardened.
However, as far as I can judge the list includes all packages which exhibit runtime problems; so far, my system appears to be stable with that list.

Quote:

As far as I understand both -flto and -fwhole-program don't work very well together and that combination is discouraged.

No, quite the opposite: Originally - when flto was first introduced - the intention was to use -flto and -fwhole-program together for the final linking. However, one had to be careful to specify -fwhole-program only for the linking phase but not for the compiling phase. Since this turned out difficult in practice, it was decided to ignore -fwhole-program for the compiling phase. So it is now safe to use it in both phases and indeed recommended for -flto unless memory or compile time restrictions speak against it.
The only thing one has to take care of is that it should of course only be used for linking the program but not for linking a library (because it might optimize needed symbols away). Therefore, I globally disable it for all packages matching *-lib/* and similar wiildcards where it will certainly be wrong to use it: It is wrong for every package which installs *.so* files.

Yeah I'd definitely give it another go, Gold is stable as all hell for me, my only issues with compiler flags has been forcing fPIE in CFLAGS and CXXFLAGS and -pie in LDFLAGS, I went through all the packages though and only about 20 or 30 of them didn't build with fPIE+pie out of about 1100 installed. Setting fstack-protector-all had no issues what so ever. I have noticed though that the certain packages that didnt build with fPIE and -pie explicility specified in make.conf actually were position independent executables in Debian, I have to figure out how they did that and were able to build with pie when I couldn't.

I did a full recompile of my system with gold. No stability problems, so far.
Aside fpc and lazarus which does not accept gold, only gettext and kernel failed with gold.
There were a few others problems related to the new gperf-3.1, well systemd error scare me a bit until the real cause was elucidated.

What I observed doing comparatives genlop -t, or better said, what I did not observed, is the speed gain of ld.gold. Did bfd catch up in the mean time ?_________________Sorry for my English. I'm still learning this language.

I did a full recompile of my system with gold. No stability problems, so far.
Aside fpc and lazarus which does not accept gold, only gettext and kernel failed with gold.
There were a few others problems related to the new gperf-3.1, well systemd error scare me a bit until the real cause was elucidated.

What I observed doing comparatives genlop -t, or better said, what I did not observed, is the speed gain of ld.gold. Did bfd catch up in the mean time ?

If that's the case it mean there are no real advantages using ld.gold with lto.

Hey don't talk bad about gold like that

Nah, Gold actually helps out LTO a bit, mainly with -fuse-linker-plugin and other friends enabled, they go hand in hand my friend. No gold, no LTO, that's how I roill, but I dropped bfd regardless if I'm using LTO or not. Gold all the way, EEEEEYAOOOO! Finally finished moving by the way, I should be returning to kernel hacking shortly.

Also, if you're running into issues compiling the kernel with the default linker set to Gold, you need to update your kernel.

Ok, ok, I surrender. There is, at least, the benefit of size when using gold, with or without lto. Nice catch.
Regarding binaries sizes I was impressed by musl. Too bad it does not support all usual desktop packages and it is a bit slow than glibc.
I do not know... first was icc, and, in time gcc surpass it (except when using their math libs), then llvm which now is on pair with gcc and slower during compile time (sic). Maybe is time to not believe in every wheel reinvent.