LTO Build Improvements
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: Jeff Law
- Email: law@redhat.com
Current status
- (Originally) Targeted release: Fedora 35
- Currently deferred
- Last updated: 2021-11-06
- FESCo issue: #2541
- Tracker bug: #1916921
- Release notes tracker: <will NOT be assigned by the Wrangler, not user-facing>
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.
Feedback
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: #9934 (a check of an impact with Release Engineering is needed)
This should have no release engineering impacts.
- Policies and guidelines:
The new macro will be a requirement for packages that install .o/.a files. So the packaging guidelines will need to be updated to clearly indicate that -static packages and more generally any package that installs a .o/.a file will need to use 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.