Full rebuild required on gcc-14, gcc-15?

tld · Veteran Joined: 09 Dec 2003 Posts: 1846

[Administrator note: this post, and the first 12 responses, were originally attached to the topic gcc-14 - cannot build sys-apps/lm-sensors. -Hu]

Sorry if this is a bit OT but just to clarify: I keep seeing posts about a recompile of everything. That's not a requirement for gcc 14 is it? Also. will that be a requirement for gcc 15?

Thanks!
Tom

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2460

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3920

I have no general answer.

Nevertheless when LTO is involved there, it should mentionned there are LTO step signature which must be matching when 2 packages are involved.
Let's supposed a dependency package D for package A has been LTO build in the past with a gcc that signs LTO level=X
Current gcc involved in building package A with LTO may be distant enough with the one used above to now sign LTO level=X+1 and would require the that very same LTO level=X+1 in the dependency package too. Build will break otherwise.

This happened here with D from gcc:13 and A build attempt with gcc:14.
It also happened with D from early gcc:14 and much later gcc:14.

Please note gcc ebuild doesn't inform when LTO step has changed.
This is something you get to know the hard way.

Back in the past I used to rebuild world after installing a new gcc.
I recall I had a feeling things to be snappier. Maybe better GUI environment.

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3920

Moreover, how to identify packages requiring clang/gcc tool stack?
Vast majority of such ebuilds don't tell easily.

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2460

freke · Posted: Thu Nov 28, 2024 2:17 pm Post subject:

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3920

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3920

World should be avoided.

Wise cherry picking specific packages to rebuild may have interesting benefit locally.

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

sam_ · Developer Joined: 14 Aug 2020 Posts: 1991

Hu · Administrator Joined: 06 Mar 2007 Posts: 22736

LTO bytecode in static archives can cause problems, yes. The solution to that is (1) don't build static archives if you can avoid it, and (2) if you cannot avoid it, prioritize rebuilding the packages that provide those static archives. Most packages will not have built static archives, and so will not need to be rebuilt due to a newer LTO bytecode version. On my system, I have more than 10 times as many shared objects in /usr/lib64 than I have static archives. Of those static archives I reviewed for this post, none came from packages that respect USE=static-libs. Only 26 packages would need to be rebuilt to cover all my static archives, out of more than 1000+ packages if I ran emerge -e @world.

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3920

I understand I might be problematic if binary packages D are involved... Maybe not.

The solution here is to rebuild dependancy package with later gcc.
Then rebuild any installed packages that relies on it with later gcc.

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

CaptainBlood · Advocate Joined: 24 Jan 2010 Posts: 3920

@Hu
I was just answering

Hu · Administrator Joined: 06 Mar 2007 Posts: 22736

While emerge --emptytree will achieve that result, it is a very expensive way to achieve a result that could be achieved far more cheaply with some targeted intervention. I sought to explain the cheap way (rebuild exactly those packages you need), and document how much cheaper it can be. For my system, it is a difference of 26 versus 1000+ packages, and most of those 26 look relatively cheap to build, so the time and power savings is even more favorable than just 26/1000, since I don't have to rebuild huge packages like llvm and firefox, because those didn't install any static archives.

The Gentoo bug that sam_ linked shows that there is interest in making this work without user intervention, but for now, users who globally apply LTO, even to packages that install static archives, will need to give the package manager a bit of extra guidance when doing a compiler upgrade.

logrusx is mostly correct though: LTO should not change ABI, and the problem is one case where LTO information is not discarded by the end of the build, and is instead persisted in a static archive for later builds to find and trip over.