From Fedora Project Wiki
(Undo revision 708868 by Tstellar (talk))
Tag: Undo
 
(33 intermediate revisions by 3 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 18 <!-- The name of your change proposal --> =
= LLVM 18 <!-- The name of your change proposal --> =


{{Change_Proposal_Banner}}


== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
Update all llvm sub-projects in Fedora Linux to version 17.  
Update all llvm sub-projects in Fedora Linux to version 18.  
== Owner ==
== Owner ==
<!--  
<!--  
Line 27: Line 20:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF40]]
<!-- 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 34: Line 27:


<!-- 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/f40/ Fedora Linux 40]
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40]
Line 45: Line 38:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* [<will be assigned by the Wrangler> devel thread]
* [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/6DA2YXSL6VYRG5AL2CLSN46JNDYQYEA3/ Announced]
* FESCo issue: <will be assigned by the Wrangler>
* [https://discussion.fedoraproject.org/t/f40-change-proposal-llvm-18-system-wide/100081 discussion thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/3139 #3139]
* Release notes tracker: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2258084 #2258084]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/1072 #1072]


== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
All llvm sub-projects in Fedora will be updated to version 18, and there will be a soname version change for the llvm libraries. Compatibility packages clang17, llvm17, and lld17 will be added to ensure that packages that currently depend on clang and llvm version 17 libraries will continue to work.  These older compatibility packages will be orphaned:
All llvm sub-projects in Fedora will be updated to version 18, and there will be a soname version change for the llvm libraries. Compatibility packages clang17, llvm17, and lld17 will be added to ensure that packages that currently depend on clang and llvm version 17 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.  We also plan to retire these older compatibility packages (that we own):


* llvm14
* llvm14
Line 63: Line 57:
* lld15
* lld15
* lld16
* lld16
We will also be asking the maintainers of the following packages to retire them if possible:
* llvm7.0
* llvm8.0
* llvm11
* llvm12
* llvm13


Other notable changes:  
Other notable changes:  


* clang will emit DWARF-5 by default instead of DWARF-4.  This matches the upstream default.  We have been using DWARF-4 as the default for the last few releases due to: https://bugzilla.redhat.com/show_bug.cgi?id=2064052
* clang will emit DWARF-5 by default instead of DWARF-4.  This matches the upstream default.  We have been using DWARF-4 as the default for the last few releases due to: https://bugzilla.redhat.com/show_bug.cgi?id=2064052
* [UNCONFIRMED] The compatibility packages will now include the same content as the main package.  In previous releases, the compat packages contained only libraries and headers.  The binaries and other content was stripped out.
* The compatibility packages will now include the same content as the main package.  In previous releases, the compatibility packages contained only libraries and headers, and the binaries and other content was stripped out.  These packages will be supported for use as dependencies for other RPM packages, but not for general purpose usage by end users.  Fedora users should use Clang/LLVM 18.
* [UNCONFIRMED] We will be adding an llvm19 package to rawhide which will be used to package periodic snapshots from upstream LLVM.  We are also investigating switching to python-like parallel versions for Fedora 41, and if we decided to do this, then llvm19 will become the 'main' llvm package in Fedora 41.
* The compatibility packages added for Fedora 40 will be retired prior to the Fedora 41 branch.
* [UNCONFIRMED] We will be enabling the FAT LTO feature.
* We will be enabling Fat LTO in redhat-rpm-config if this feature is complete in time for the upstream LLVM 18 release.  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 39 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.


===LLVM Build Schedule===
===LLVM Build Schedule===
Line 75: Line 77:
====Important Dates====
====Important Dates====


* Jan  27: Upstream: 18.0.0-rc1 Release
* Jan  26: Upstream: 18.0.0-rc1 Release
* Feb  6: Fedora: f40 branch created
* Feb  6: Fedora: f40 branch created
* Feb  6: Upstream: 18.0.0-rc2 Release
* Feb  6: Upstream: 18.0.0-rc2 Release
Line 84: Line 86:


====Plan====
====Plan====
 
# Build nightly trunk (LLVM 18) snapshots in [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/packages/ copr].
# Build LLVM 18.0.0-rc1 in COPR.
# Build LLVM 18.0.0-rc1 in COPR.
# Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
# Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
# Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji.
# Build LLVM 18.0.0-rc1 into a f40 side-tag in Koji.
# Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
# Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
# Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji.
# Build LLVM 18.0.0-rc2 into a f40 side-tag in Koji.
# Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
# Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
# Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji
# Build LLVM 18.0.0-rc3 into a f40 side-tag in Koji
# Push F39 Bodhi Update with 18.0.0-rc3 (or 17.0.0-rc2 if -rc3 is not ready) as a Beta Freeze exception.
# Push F40 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not ready) as a Beta Freeze exception.
# Continue building new release candidates and pushing them to stable until the Final Freeze.
# Continue building new release candidates and pushing them to stable until the Final Freeze.


We are not planning to push 18.0.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.  The worst case scenario would be an ABI change -rc4 or the fianl release that we force us to patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario would not require rebuilding LLVM library users in Fedora, so this would not require much extra work from our team.
We are not planning to push 18.0.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.  The worst case scenario would be an ABI change -rc4 or the final release that we force us to patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario would not require rebuilding LLVM library users in Fedora, so this would not require much extra work from our team.


Updates after 17.0.0-rc3 will generally be very small and can be done after the Final Freeze is over.  If we are late packaging release candidates after -rc3 or the final release, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug.
Updates after 18.0.0-rc3 will generally be very small and can be done after the Final Freeze is over.  If we are late packaging release candidates after -rc3 or the final release, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug.


== Feedback ==
== Feedback ==
Line 136: Line 138:
<!-- 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.
** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used.
** Do scratch builds of Fedora packages that depend on llvm and report issues to package maintainer.
** Build and test early release candidates of LLVM 18 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-18 or switch their package to use the llvm16 compat libs.  The LLVM team no longer plans to block Bodhi updates on dependent packages that fail to build or run with LLVM-18.  There should be around 6-8 weeks between when -rc1 lands in koji and the Final Freeze for package maintainers to fix issues uncovered with the LLVM-18 update.
** Fix build issues found with LLVM-18 or switch their package to use the llvm17 compat libs.  The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-18.  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-18 update.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/11845 #11845] <!-- 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 196: Line 197:


<!-- 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 LLVM18 or will need to switch to using one of the llvm17 compat packages.


== Contingency Plan ==
== Contingency Plan ==
Line 202: Line 203:
<!-- 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?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
If there are major problems with LLVM 17, the compatibility package provide a way for other packages to continue using LLVM 16.  
If there are major problems with LLVM 18, the compatibility package provide a way for other packages to continue using LLVM 17.  
<!-- 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: Final Freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Final Freeze  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Latest revision as of 00:50, 4 May 2024


LLVM 18

Summary

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

Owner

Current status

Detailed Description

All llvm sub-projects in Fedora will be updated to version 18, and there will be a soname version change for the llvm libraries. Compatibility packages clang17, llvm17, and lld17 will be added to ensure that packages that currently depend on clang and llvm version 17 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. We also plan to retire these older compatibility packages (that we own):

  • llvm14
  • llvm15
  • llvm16
  • clang14
  • clang15
  • clang16
  • lld14
  • lld15
  • lld16

We will also be asking the maintainers of the following packages to retire them if possible:

  • llvm7.0
  • llvm8.0
  • llvm11
  • llvm12
  • llvm13

Other notable changes:

  • clang will emit DWARF-5 by default instead of DWARF-4. This matches the upstream default. We have been using DWARF-4 as the default for the last few releases due to: https://bugzilla.redhat.com/show_bug.cgi?id=2064052
  • The compatibility packages will now include the same content as the main package. In previous releases, the compatibility packages contained only libraries and headers, and the binaries and other content was stripped out. These packages will be supported for use as dependencies for other RPM packages, but not for general purpose usage by end users. Fedora users should use Clang/LLVM 18.
  • The compatibility packages added for Fedora 40 will be retired prior to the Fedora 41 branch.
  • We will be enabling Fat LTO in redhat-rpm-config if this feature is complete in time for the upstream LLVM 18 release. 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 39 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.

LLVM Build Schedule

Important Dates

  • Jan 26: Upstream: 18.0.0-rc1 Release
  • Feb 6: Fedora: f40 branch created
  • Feb 6: Upstream: 18.0.0-rc2 Release
  • Feb 20: Fedora: f40 Beta Freeze
  • Feb 20: Upstream: 18.0.0-rc3 Release
  • Mar 5: Upstream: 18.0.0 Release
  • Apr 2: Fedora: f40 Final Freeze

Plan

  1. Build nightly trunk (LLVM 18) snapshots in copr.
  2. Build LLVM 18.0.0-rc1 in COPR.
  3. Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
  4. Build LLVM 18.0.0-rc1 into a f40 side-tag in Koji.
  5. Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
  6. Build LLVM 18.0.0-rc2 into a f40 side-tag in Koji.
  7. Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
  8. Build LLVM 18.0.0-rc3 into a f40 side-tag in Koji
  9. Push F40 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not ready) as a Beta Freeze exception.
  10. Continue building new release candidates and pushing them to stable until the Final Freeze.

We are not planning to push 18.0.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. The worst case scenario would be an ABI change -rc4 or the final release that we force us to patch LLVM to maintain compatibility with the -rc3 ABI. This scenario would not require rebuilding LLVM library users in Fedora, so this would not require much extra work from our team.

Updates after 18.0.0-rc3 will generally be very small and can be done after the Final Freeze is over. If we are late packaging release candidates after -rc3 or the final release, we will not ask for a Final Freeze exception, unless they contain a fix for a critical release blocking bug.

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 18 in COPR.
  • Other developers:
    • Fix build issues found with LLVM-18 or switch their package to use the llvm17 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-18. 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-18 update.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Community Initiatives:

Upgrade/compatibility impact

This change should not impact upgrades.

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 18.

User Experience

Dependencies

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

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)

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

  • Contingency deadline: Final Freeze
  • Blocks release? No

Documentation

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

  • llvm
  • clang
  • lld
  • lldb
  • compiler-rt
  • libomp
  • 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-18&oldid=708876"