On 1/4/21 12:22 PM, Tom Stellard wrote: > On 12/30/20 11:52 AM, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/LTOBuildImprovements >> >> >> == Summary == >> Currently all packages that are not opted out of LTO include >> -ffat-lto-objects in their build flags. This proposal would remove >> -ffat-lto-objects from the default LTO flags and only use it for >> packages that actually need it. >> >> == Owner == >> * Name: [[User:law | Jeff Law]] >> * Email: law@xxxxxxxxxx >> >> >> == Detailed Description == >> -ffat-lto-objects was added to the default LTO flags to ensure that >> any installed .o/.a files included actual compiled code rather than >> just LTO bytecodes (which are stripped after the install phase). >> However, that is wasteful from a compile-time standpoint as few >> packages actually install any .o/.a files. >> >> This proposal would remove -ffat-lto-objects from the default LTO >> flags and packages that actually need the option would have to opt-in >> via an RPM macro in their .spec file. This should significantly >> improve build times for most packages in Fedora. >> > > What is this macro going to be called? I would like to get an early > start on updating my packages. No idea. I'm open to suggestions. IIRC we had kicked around the idea of having the clang/llvm path instantiate the LTO bytecodes in .o/.a files, which would avoid these issues for packages using clang/llvm. Is that something we still want to pursue? I vaguely recall discussing this with David B. and he came up with a reason why that needed to happen before brp-strip-lto, but I can't remember any of the details at this point. Jeff _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx