Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 926120

Summary: Figure out proper handling for LTO static libraries
Product: Gentoo Linux Reporter: Sam James <sam>
Component: Current packagesAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: CONFIRMED ---    
Severity: normal CC: arsen, eschwartz, gabifalk, kocelfc, matoro_gentoo, mmk
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=866422
https://bugs.gentoo.org/show_bug.cgi?id=618550
https://bugs.gentoo.org/show_bug.cgi?id=920745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114505
https://bugs.gentoo.org/show_bug.cgi?id=927994
https://bugs.gentoo.org/show_bug.cgi?id=936172
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 876430, 900519, 924183, 924360    

Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-03-04 03:42:10 UTC
I kept thinking we had a proper bug for this, but we didn't AFAIK. I shorehorned it into bug 866422 for a while.

With static libraries and -flto, bitcode is included in the static archive (.a) and then when an application links using them later on, they're glued together and treated as the whole program. It allows more optimisation, but it's very brittle.

The archives aren't compatible across GCC versions, even minor versions (depends on if a commit which changes certain interals gets backported). The interface version isn't always updated for such commits which causes a segfault/ICE instead of a nicer error for mismatched versions.

We don't generally bother with static libraries and we can take the loss on optimising them, especially given it also often blows up memory usage with LTO too.
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-03-04 03:43:48 UTC
Fedora has two approaches:
1) For GCC, it checks that -ffat-lto-objects was used (they warn if not - https://fedoraproject.org/wiki/Changes/LTOBuildImprovements), and strips the bitcode from the static libraries using https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/brp-strip-lto

2) For LLVM, they try to convert the bitcode to ELF (https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/brp-llvm-compile-lto-elf).
Comment 2 Eli Schwartz gentoo-dev 2024-03-04 03:46:56 UTC
So naively, a paired set of functions?

In src_configure:

lto-guarantee-fat() {
	if tc-is-lto; then
		append-cflags $(test-flags-CC -ffat-lto-objects)
		append-cxxflags $(test-flags-CXX -ffat-lto-objects)
	fi
}


in src_install, manually strip with -R .gnu.lto_* -R .gnu.debuglto_* -N __gnu_lto_v1

Or hook this up to portage's global stripping routine. See bug 920745.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-03-04 03:49:48 UTC
(In reply to Eli Schwartz from comment #2)

I suppose this isn't that bad... especially given not _that_ many packages even install static libraries.

We need to see if we can make the same approach work for LLVM too, ideally. I wouldn't want to have to do two approaches...
Comment 5 Arsen Arsenović gentoo-dev 2024-03-04 18:57:48 UTC
I was and potentially am still partial to post-processing static libraries by compiling them (or their contents) with '-x lto'.  I haven't experimented with this at all, however, so it is entirely possible that it's not possible for some reason.

The reason for me holding on to it is because it'd be less error-prone (maintainers wouldn't have to know ahead of time whether static libraries are being installed) and maybe faster.

If someone plays around with this, please consider it.
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-03-05 08:56:33 UTC
(In reply to Arsen Arsenović from comment #5)
> I was and potentially am still partial to post-processing static libraries
> by compiling them (or their contents) with '-x lto'.
> [...]

> The reason for me holding on to it is because it'd be less error-prone
> (maintainers wouldn't have to know ahead of time whether static libraries
> are being installed) and maybe faster.

I don't think it's less error prone because if we were to do it, it'd have to be in Portage (so PM-specific) and also figure out a way for ebuilds to control it...

> 
> If someone plays around with this, please consider it.

But I haven't given up on the idea and I will keep your preference in mind, of course
Comment 7 Arsen Arsenović gentoo-dev 2024-03-05 10:36:33 UTC
(In reply to Sam James from comment #6)
> (In reply to Arsen Arsenović from comment #5)
> > I was and potentially am still partial to post-processing static libraries
> > by compiling them (or their contents) with '-x lto'.
> > [...]
> 
> > The reason for me holding on to it is because it'd be less error-prone
> > (maintainers wouldn't have to know ahead of time whether static libraries
> > are being installed) and maybe faster.
> 
> I don't think it's less error prone because if we were to do it, it'd have
> to be in Portage (so PM-specific) and also figure out a way for ebuilds to
> control it...

But the default is, IMO, far better.  Packages that fail to build in that way are likely exceptions rather than the rule.

But yes, the rest stands..

> > 
> > If someone plays around with this, please consider it.
> 
> But I haven't given up on the idea and I will keep your preference in mind,
> of course

Thanks :-)
Comment 8 Eli Schwartz gentoo-dev 2024-03-27 21:36:27 UTC
This came up during the 23.0 profile migration as well.

The global USE default now enables zstd, which therefore toggles the gcc IUSE and enables zstd-compressed LTO bytecode.

GCC promptly emits an ICE when linking against existing static archives that were built with a GCC that was configured to use zlib instead of zstd.

This is a general problem if you rebuild the compiler with changed USE...
Comment 9 Eli Schwartz gentoo-dev 2024-03-27 21:42:52 UTC
find /usr/lib* -name '*.a' | xargs equery belongs | sort -u

38 packages on my system. It is not a pleasant idea when doing a profile migration and --emptytree if you have to build all of those with LTO disabled before migrating, then rebuild them again with LTO to taste.
Comment 10 Arsen Arsenović gentoo-dev 2024-03-28 14:44:26 UTC
jakub has also suggested the fat-lto-object approach.  maybe we should make a 'dot-a.eclass' for adding + processing installed lto objects and object archives, plus a QA check that detects packages forgetting to use them.  this seems PM-independent but still solid enough