On Wed, Dec 30, 2020 at 7:54 PM Ben Cotton <bcot...@redhat.com> 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: l...@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. > Does this mean that packages that are explicitly shipping a static library to the end user need to enable this macro to allow the installed static library to be usable by an end-user's compiler? If this is the case, then the packaging guidelines should be updated to reflect this. > > 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-le...@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 >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
