Zbigniew Jędrzejewski-Szmek <[email protected]> writes: > 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. >
This seems reasonable to me, though a little more aggressive than adding an option that packagers can use. > 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
