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@redhat.com
== 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.
To ensure that we can identify packages that need the opt-in now and in the future, the plan is to pass to brp-strip-lto a flag indicating whether or not the package has opted into -ffat-lto-objects. If brp-strip-lto finds .o/.a files, but the package has not opted into -ffat-lto-objects, then brp-strip-lto would signal an error.
== Benefit to Fedora == The key benefit to Fedora is improved package build times and lower load on the builders.
== Scope == * Proposal owners: The feature owner (Jeff Law) will need to settle on a suitable RPM macro to indicate an opt-in to -ffat-lto-objects, implement the necessary tests in brp-strip-lto and opt-in the initial set of packages. This will be accomplished by doing the prototype implementation locally, building all the Fedora packages to generate the opt-in set. Committing the necessary opt-ins, then committing the necessary changes to the RPM macros.
* Other developers: There should be minimal work for other developers. The most likely scenarios where other developers will need to get involved would include: # Packages which are excluded from x86_64 builds and which need the opt-in will need the appropriate package owners to add the opt-in. # Packages which are FTBFS when the builds are run to find the set of packages that need to opt-in and which need to opt-in will need packager attention. # It is possible that the faster builds may trigger build failures in packages that have missing dependencies in their Makefiles. We saw a few of these during the initial LTO work and those packages were either fixed or -j parallelism removed. This work may expose more of these problems.
I expect these all to be relatively rare occurences, but with 9000+ packages in Fedora I wouldn't be surprised if we see a few of each of these issues.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) This should have no release engineering impacts. * Policies and guidelines: The packaging guidelines will need to be updated to document the new macro. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: This proposal does not align with any current Fedora Objectives.
== Upgrade/compatibility impact == This change should have zero impact on upgrade/compatibility. In fact, the change should have no user visible impacts.
== How To Test == No special testing is needed. Any issues with this proposal will show up as FTBFS issues.
== User Experience == Users should see no changes to the user experience.
== Dependencies == Packages which need to opt-in to -ffat-lto-objects will need their .spec files updated to include the new macro.
== Contingency Plan == If this can not be completed by final development freeze, then the RPM macro changes would not be installed and the change could defer to Fedora 35. * Contingency mechanism: Proposal owner will only commit the RPM macro changes once the opt-in package set has been identified and opt-ins added to those package's spec files. So no special contingency mechanism should be needed * Contingency deadline: It is most beneficial to have this completed before the mass rebuild; however, the drop dead date should be beta freeze. * Blocks release? No * Blocks product? No
== Documentation == No upstream documentation. Packaging guidelines will need a minor update.
== Release Notes == I do not expect this change to require any release notes.
devel-announce@lists.fedoraproject.org
-
Ben Cotton