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. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
