On Sat, Sep 05, 2026 at 08:57:15AM -0400, Neal Gompa wrote: > On Sat, Sep 5, 2026 at 8:50 AM Zbigniew Jędrzejewski-Szmek > <[email protected]> wrote: > > > > On Fri, Sep 04, 2026 at 04:39:30PM +0200, Jakub Jelinek via devel wrote: > > > On Fri, Sep 04, 2026 at 04:05:01PM +0200, Florian Weimer via devel wrote: > > > > * Benjamin Beasley: > > > > > > > > > On the other hand, if this change is less about packages that > > > > > currently can’t use LTO and more about trying to save build time for > > > > > packages that already successfully build with fat LTO objects, then > > > > > how much builder time can be saved? And what, if any, effect on the > > > > > performance of the compiled programs can be expected? If this is a > > > > > compile-time/runtime performance tradeoff, it’s hard to make an > > > > > informed decision without knowing what is being traded for what. > > > > > > > > Assuming this is about not using -ffat-lto-objects with GCC, there > > > > should not be a change in generated machine code as a result of this. > > > > It just drops non-LTO code generation that we currently discard anyway. > > > > > > We don't discard it in all cases though. > > > It is ignored when linking binaries/shared libraries with -flto and where > > > the LTO sections are present too. > > > We strip the LTO sections in *.a libraries included in packages (or in the > > > rare case where packages include *.o objects), and in that case without > > > -ffat-lto-objects it wouldn't work at all. > > > > > > So, sure, we could drop -ffat-lto-objects for packages which don't include > > > in %files any *.a/*.o files (most of them), but packages which include > > > those > > > (even when just in some binary subpackages) wouldn't work without it (or > > > one > > > would need to judge what should be compiled with that flag and what can > > > avoid it depending on in what it will be linked or archived). > > > > In that case, shouldn't this approach be inverted: > > - drop -ffat-lto-objects by default > > - add '%global _lto_cflags %_lto_flags_fat' > > - add a test either in CI or in rpmlint that no empty .a/.o files are being > > shipped in the package. > > - fix any packages that _do_ require fat lto objects to use > > '%global _lto_cflags %_lto_flags_fat'. > > > > Then we should get more efficient builds for the 99% of packages that don't > > ship .a/.o. Some packages would need to be adjusted, but the help would help > > find cases that need the adjustment. > > > > AFAIK, one reason for fat LTO objects is to have interoperability > between different compilers in mixed compiler builds with LTO. That's > a pretty good reason to have them by default, since normally LTO can't > handle a situation where you have GCC, Clang, and rustc (as an > example) operating in the same codebase.
Isn't this something that is rather rare? While packages using clang or rust _are_ fairly common, how often do they use two compilers? Zbyszek -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
