From Fedora Project Wiki

< Changes

Revision as of 02:11, 29 December 2020 by Law (talk | contribs) (Created page with "<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> =...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


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

Current status

  • Targeted release: Fedora 34
  • Last updated: 2020-12-29
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

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:

  1. 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.
  2. 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.
  3. 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.


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.

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/LTOBuildImprovements&oldid=598966"