I'm not sure if I made a mistake when testing this before or if it changed
when the strip patch did, but the new behaviour is fine too with the
latest patch for Binutils.
I think what happened is that the patch changed to only mangle with -R ...
where ... is for LTO sections, which is fine for us. But doing this in a
separate commit so I can revert it easily if needed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=21479#c13.
Signed-off-by: Sam James <sam@gentoo.org>
Introduce a new eclass with utility functions for handling LTO bytecode
(or internal representation, IR) inside static archives (.a files).
Static libraries when built with LTO will contain LTO bytecode which is
not portable across compiler versions or compiler vendors. To avoid pessimising
the library and always filtering LTO, we can build it with -ffat-lto-objects
instead, which builds some components twice. The installed part will then
have the LTO contents stripped out, leaving the regular objects in the
static archive.
It's not feasible to make these work otherwise, as we'd need tracking
for whether a library was built by a specific compiler and its version,
and that compatibility can vary based on other factors (e.g. with gcc,
sys-devel/gcc[zstd] controls if it supports zstd compression for LTO). We
also discourage static libraries anyway.
Provide two functions:
* lto-guarantee-fat
If LTO is currently enabled (as determined by `tc-is-lto`, added in
2aea6c3ff2), add `-ffat-lto-objects`
to CFLAGS and CXXFLAGS if supported.
This guarantees that produced archives are "fat" (contain both IR
and regular object files) for later pruning.
* strip-lto-bytecode
Process a given static archive (.a file) and remove its IR component,
leaving a regular object.
This approach is also taken by Fedora, openSUSE, and Debian/Ubuntu. An
honourable mention to `lto-rebuild` which fulfilled the same task for many
in the LTO overlay too.
We did consider an alternative approach where we'd relink objects using
the driver in src_install (or some hook afterwards), but this would be
more brittle, as we'd need to extract the right arguments to use (see
e.g. the recent Wireshark issues in fad8ff8a45
for how this can be subtle) and not PM-agnostic given we don't have portable
hooks right now (and even if we did, suspect they wouldn't work in a way
that facilitated this). It's also not clear if such an approach would've
worked for Clang.
The tests have been quite helpful in debugging this and making sure things
work as expected. They both make sure the eclass does what it ought to,
but also try to capture the expected interaction with the toolchain (which is
why we have the skips depending on tooling & versions) to allow us to test
workarounds and make sure we understand the interactions fully: it made
it easy to test e.g. a patch to Binutils to make strip have plugin/LTO
integration (PR21479).
All of this wasn't worth pursuing until H. J. Lu's patches for Binutils
landed, which they have now in binutils-2.44 [0], which made bfd's handling
of mixed objects much more robust.
[0] https://inbox.sourceware.org/binutils/20250112220244.597636-1-hjl.tools@gmail.com/
Bug: https://bugs.gentoo.org/926120
Thanks-to: Arsen Arsenović <arsen@gentoo.org>
Co-authored-by: Eli Schwartz <eschwartz@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
- bump to EAPI=8
- drop USE=X to disable eximon
eximon is very old, and probably not that much maintained code. It
isn't enabled by default (upstream) and relies on X, which is dated. It
doesn't compile with -std=c23, and upstream has the habit of refusing
any fix for compiler warnings/errors, so just disable eximon, as it is
just a client tool, the MTA is unaffected.
Closes: https://bugs.gentoo.org/955368
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
This drops ppc64 but it was stuck on an old version anyway. We can bring
it back later once that is sorted.
Bug: https://bugs.gentoo.org/899974
Signed-off-by: Sam James <sam@gentoo.org>
David Roman
Robert Siebeck
Sam James
Michał Górny
Tomasz Śliwa
Fabian Groffen
Kirill Chibisov
Joonas Niilola
Filip Kobierski
Alexander Kurakin
Azamat H. Hackimov
Eric Joldasov
Arthur Zamarin
Hans de Graaff