From Fedora Project Wiki
(retargeting change to F42)
 
(25 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
{{admon/tip | Guidance | For details on how to fill out this form, see the [https://docs.fedoraproject.org/en-US/program_management/changes_guide/ documentation].}}
{{admon/tip | Report issues | To report an issue with this template, file an issue in the [https://pagure.io/fedora-pgm/pgm_docs pgm_docs repo].}}
<!-- 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 -->
<!-- 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 -->


= LLVM 19 <!-- The name of your change proposal --> =
= LLVM 19 <!-- The name of your change proposal --> =


{{Change_Proposal_Banner}}


== Summary ==
== Summary ==
Line 28: Line 21:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF42]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 35: Line 28:


<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
<!--[[Category:SelfContainedChange]]-->
<!-- [[Category:SystemWideChange]] -->
[[Category:SystemWideChange]]
 
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f42/ Fedora Linux 41]
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f<VERSION>/ Fedora Linux <VERSION>]
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 46: Line 38:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* [Announced]
* [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/ZJAFWUAUFOQCOZOL7UBGH6PPA5KGPQTR/ Announced]
* [<will be assigned by the Wrangler> Discussion thread]
* [https://discussion.fedoraproject.org/t/f41-change-proposal-llvm-19-system-wide/118552 Discussion thread]
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/3220 #3220]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2293629 #2293629]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://gitlab.com/fedora/docs/fedora-linux-documentation/release-notes/-/issues/114 #114]


== Detailed Description ==
== Detailed Description ==
Line 67: Line 59:
* '''Build compat packages (e.g. llvm18) as early as possible.'''  When we package a new major release of llvm, we create a compat package so that packages that aren't compatible with the new version can still use the old version.  In the past, we've waited to introduce the compat packages until the new version of LLVM was ready (typically during the Beta Freeze).  However, this proved to be an issue this release for packages the were ready to switch to the compat packages early in the release cycle, but then had to wait for Beta freeze.
* '''Build compat packages (e.g. llvm18) as early as possible.'''  When we package a new major release of llvm, we create a compat package so that packages that aren't compatible with the new version can still use the old version.  In the past, we've waited to introduce the compat packages until the new version of LLVM was ready (typically during the Beta Freeze).  However, this proved to be an issue this release for packages the were ready to switch to the compat packages early in the release cycle, but then had to wait for Beta freeze.


* '''Spec file merge.'''  We plan to merge the clang, compiler-rt, and libomp packages in with llvm and have them be sub-packages of the llvm package.  This will allow us to use the build configuration recommended by upstream and also make it possible to optimize the packages using Profile-Guided Optimizations (PGO).
* '''Spec file merge.'''  We plan to retire the clang, compiler-rt, lld and libomp packages and merge them in with llvm and have them be sub-packages of the llvm package.  All these packages have their sources in the same upstream git repository and use the same versioning.  This change will allow us to use the build configuration recommended by upstream and also make it possible to optimize the packages using Profile-Guided Optimizations (PGO). It's possible that in future releases (f42+), we may decided to merge more packages in with llvm too.
 
* '''Fat LTO'''. All RPMS built with clang will default to using the -ffat-lto option.  Fat LTO is a feature that allows the compiler to produce libraries that contain LTO bitcode along side the traditional ELF binary code so that the libraries can be linked in both LTO mode and non-LTO mode. gcc also supports this feature and has it enabled in Fedora. In Fedora 40 and older, with LTO enabled, clang produces binaries with only LTO bitcode, so we need to run a post-processing script (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code so they can be used by other packages. Enabling Fat LTO will allow us to remove this script and simplify the build process.  We originally proposed this feature for Fedora 40, but it was not ready in time.
 
===Planned Schedule===
 
Our plan is to push 19.1.0-rc3 into Fedora 41 as a Beta Freeze exception.  Updates after 19.1.0-rc3 will generally be very small and can be done after the Beta Freeze is over.  If we are late packaging releases after 19.1.0-rc3, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug.
 
We are not planning to push 19.1.0-rc1 into rawhide because the library ABI is not stabilized at that point. Typically, the ABI stabilizes after -rc3, but there are no guarantees from upstream about this.  Given the history of minimal ABI changes after -rc3, we feel like it's safe to push -rc3 into rawhide and Fedora 41.  The worst case scenario would be an ABI change in -rc4 or the final release that would force us to patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario would not require rebuilding LLVM library users in Fedora, so it would merely be a self-contained change to LLVM.
 
====Important Dates====


* '''Switch to python-style compat/main packages.'''  In order to make the packaging more consistent between the main package (e.g. llvm) and the compat package (e.g. llvm18), we would retire the un-versioned dist-git for llvm, and create a new versioned dist-git for each new release (e.g. llvm19, llvm20, llvm21 etc.).  We would then designate one of these as the 'main version', and that version would produce binary rpms that look like the current main package (i.e. llvm-libs instead of  llvm19-libs).
Dates may change depending on circumstances.


* '''Fat LTO'''. All RPMS built with clang will default to using the -ffat-lto option.  Fat LTO is a feature that allows the compiler to produce libraries that contain LTO bitcode along side the traditional ELF binary code so that the libraries can be linked in both LTO mode and non-LTO mode. gcc also supports this feature and has it enabled in Fedora. In Fedora 40 and older, with LTO enabled, clang produces binaries with only LTO bitcode, so we need to run a post-processing script (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code so they can be used by other packages. Enabling Fat LTO will allow us to remove this script and simplify the build process. We originally proposed this feature for Fedora 40, but it was not ready in time.
* Jun  4: Build llvm18, clang18, lld18, compiler-rt18, and lld18 compat packages in rawhide.
* July 26: Begin building LLVM 19.1.0-rc1 in COPR.
* Aug  6: Begin building LLVM 19.1.0-rc2 in COPR.
* '''''Aug  6: Fedora f41 branches created.'''''
* Aug  20: Begin building LLVM 19.1.0-rc3 in Rawhide and f41 side-tags.
* '''''Aug  20: Fedora f41 Beta Freeze'''''
* Aug 20-> Sep 10: Request Beta Freeze Exception and push 19.1.0-rc3 into f41 stable.
* Sep  3: Begin building LLVM 19.1.0-rc4 in Rawhide side-tag.
* Sep  17: Begin building LLVM 19.1.0 in Rawhide and f41 side-tags.
* Sep  17 -> Oct 1: Push 19.1.0 into f41 stable.
* '''''Oct  1: Fedora f41 Final Freeze.'''''


== Feedback ==
== Feedback ==
Line 104: Line 116:
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->
-->
New features and bug fixes provided by the latest version of LLVM.


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used.
** Build and test early release candidates of LLVM 19 in COPR.


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** Fix build issues found with LLVM-19 or switch their package to use the llvm18 compat libs.  The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-19.  There should be around 6-8 weeks between when -rc1 lands in the koji side-tag and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-19 update.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/12118] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 129: Line 145:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
This change should not impact upgrades.


== Early Testing (Optional) ==
== Early Testing (Optional) ==
Line 151: Line 168:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 19.


== User Experience ==
== User Experience ==
Line 168: Line 186:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
Packages that depend on one of the llvm packages will need to be updated to work with LLVM19 or will need to switch to using one of the llvm18 compat packages.


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: (What to do?  Who will do it?)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
If there are major problems with LLVM 19, the compatibility package provide a way for other packages to continue using LLVM 18.
 
* Contingency deadline:Final Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 


== Documentation ==
== Documentation ==
Line 184: Line 204:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)  
LLVM sub-projects in Fedora have been updated to version 19:
 
* llvm (now includes clang, lld, compiler-rt, libomp)
* lldb
* llvm-test-suite
* libcxx
* python-lit
* flang
* mlir
* polly
* libclc
* llvm-bolt


== Release Notes ==
== Release Notes ==

Latest revision as of 17:13, 2 October 2024


LLVM 19

Summary

Update all llvm sub-projects in Fedora Linux to version 19.

Owner


Current status

Detailed Description

All llvm sub-projects in Fedora will be updated to version 19, and there will be a soname version change for the llvm libraries. Compatibility packages clang18, llvm18, lld18, compiler-rt18, and libomp18 will be added to ensure that packages that currently depend on clang and llvm version 18 libraries will continue to work. We may add other compatibility packages too if they're determined to be necessary to maintain functionality in other RPMS that use llvm/clang. Any compatibility packages we add for Fedora 41 will be retired or orphaned before the Fedora 42 branch date. As stated in the LLVM-18 change proposal, we plan to retire or orphan these older compatibility packages prior to the Fedora 41 branch date:

  • llvm17
  • clang17
  • lld17
  • compiler-rt17
  • libomp17

Other notable changes:

  • Build compat packages (e.g. llvm18) as early as possible. When we package a new major release of llvm, we create a compat package so that packages that aren't compatible with the new version can still use the old version. In the past, we've waited to introduce the compat packages until the new version of LLVM was ready (typically during the Beta Freeze). However, this proved to be an issue this release for packages the were ready to switch to the compat packages early in the release cycle, but then had to wait for Beta freeze.
  • Spec file merge. We plan to retire the clang, compiler-rt, lld and libomp packages and merge them in with llvm and have them be sub-packages of the llvm package. All these packages have their sources in the same upstream git repository and use the same versioning. This change will allow us to use the build configuration recommended by upstream and also make it possible to optimize the packages using Profile-Guided Optimizations (PGO). It's possible that in future releases (f42+), we may decided to merge more packages in with llvm too.
  • Fat LTO. All RPMS built with clang will default to using the -ffat-lto option. Fat LTO is a feature that allows the compiler to produce libraries that contain LTO bitcode along side the traditional ELF binary code so that the libraries can be linked in both LTO mode and non-LTO mode. gcc also supports this feature and has it enabled in Fedora. In Fedora 40 and older, with LTO enabled, clang produces binaries with only LTO bitcode, so we need to run a post-processing script (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code so they can be used by other packages. Enabling Fat LTO will allow us to remove this script and simplify the build process. We originally proposed this feature for Fedora 40, but it was not ready in time.

Planned Schedule

Our plan is to push 19.1.0-rc3 into Fedora 41 as a Beta Freeze exception. Updates after 19.1.0-rc3 will generally be very small and can be done after the Beta Freeze is over. If we are late packaging releases after 19.1.0-rc3, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug.

We are not planning to push 19.1.0-rc1 into rawhide because the library ABI is not stabilized at that point. Typically, the ABI stabilizes after -rc3, but there are no guarantees from upstream about this. Given the history of minimal ABI changes after -rc3, we feel like it's safe to push -rc3 into rawhide and Fedora 41. The worst case scenario would be an ABI change in -rc4 or the final release that would force us to patch LLVM to maintain compatibility with the -rc3 ABI. This scenario would not require rebuilding LLVM library users in Fedora, so it would merely be a self-contained change to LLVM.

Important Dates

Dates may change depending on circumstances.

  • Jun 4: Build llvm18, clang18, lld18, compiler-rt18, and lld18 compat packages in rawhide.
  • July 26: Begin building LLVM 19.1.0-rc1 in COPR.
  • Aug 6: Begin building LLVM 19.1.0-rc2 in COPR.
  • Aug 6: Fedora f41 branches created.
  • Aug 20: Begin building LLVM 19.1.0-rc3 in Rawhide and f41 side-tags.
  • Aug 20: Fedora f41 Beta Freeze
  • Aug 20-> Sep 10: Request Beta Freeze Exception and push 19.1.0-rc3 into f41 stable.
  • Sep 3: Begin building LLVM 19.1.0-rc4 in Rawhide side-tag.
  • Sep 17: Begin building LLVM 19.1.0 in Rawhide and f41 side-tags.
  • Sep 17 -> Oct 1: Push 19.1.0 into f41 stable.
  • Oct 1: Fedora f41 Final Freeze.

Feedback

Benefit to Fedora

New features and bug fixes provided by the latest version of LLVM.

Scope

  • Proposal owners:
    • Review existing llvm and clang compatibility packages and orphan any packages that are no longer used.
    • Build and test early release candidates of LLVM 19 in COPR.
  • Other developers:
    • Fix build issues found with LLVM-19 or switch their package to use the llvm18 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-19. There should be around 6-8 weeks between when -rc1 lands in the koji side-tag and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-19 update.
  • Release engineering: [1]
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact

This change should not impact upgrades.

Early Testing (Optional)

Do you require 'QA Blueprint' support? Y/N

How To Test

The CI tests for the llvm sub-packages in Fedora will be used to catch regressions that might be potentially introduced by the update to LLVM 19.

User Experience

Dependencies

Packages that depend on one of the llvm packages will need to be updated to work with LLVM19 or will need to switch to using one of the llvm18 compat packages.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)

If there are major problems with LLVM 19, the compatibility package provide a way for other packages to continue using LLVM 18.

  • Contingency deadline:Final Freeze
  • Blocks release? No (not a System Wide Change), Yes/No

Documentation

LLVM sub-projects in Fedora have been updated to version 19:

  • llvm (now includes clang, lld, compiler-rt, libomp)
  • lldb
  • llvm-test-suite
  • libcxx
  • python-lit
  • flang
  • mlir
  • polly
  • libclc
  • llvm-bolt

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/LLVM-19&oldid=721314"