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.


--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org