F42 Change Proposal: LLVM 20 (system-wide)

Project Discussion Change Proposals
,
1

LLVM 20

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

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

:link: Owner

All llvm sub-projects in Fedora will be updated to version 20. There will be a soname version change for the llvm libraries, and an llvm19 compat package added to ensure that packages that currently depend on clang and llvm version 19 libraries will continue to work.

Other notable changes:

  • Install Prefix Changes The install prefix for all new llvm packages will be /usr/lib64/llvm$VERSION/ instead of /usr/. There will be symlinks for each binary and library added to /usr/ which point to the corresponding binary in /usr/lib64/llvm$VERSION/ The goal of this change is to reduce the differences between the compat and non-compat versions so that it it easier for packages that depend on llvm to switch between the two.

  • Merging more packages into llvm In Fedora 41, we merged the clang, libomp, compiler-rt, lld, python-lit, and lldb packages into the llvm srpm. For Fedora 42, we will also be merging llvm-bolt, polly, libcxx, and mlir into the llvm20 srpm.

:link: Planned Schedule

Our plan is to push 20.1.0-rc3 into Fedora 42 as a Beta Freeze exception. Updates after 20.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 20.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 20.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 42. 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.

:link: Important Dates

  • Jan 31: Begin building LLVM 20.1.0-rc1 in COPR.
  • Feb 4: Fedora f42 branches created
  • Feb 11: Begin building LLVM 20.1.0-rc2 in COPR.
  • Feb 18: Fedora f42 beta freeze
  • Feb 25: Begin building LLVM 20.1.0-rc3 in Rawhide and f42 side-tags.
  • Feb 25-> Mar 11: Request Beta Freeze Exception and push 20.1.0-rc3 into f42 stable.
  • Mar 11: Begin building LLVM 20.1.0-rc4 in Rawhide side-tag.
  • Mar 25: Begin building LLVM 20.1.0 in Rawhide and 42 side-tags.
  • Apr 1: Fedora f42 final freeze

:link: Feedback

:link: Benefit to Fedora

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

:link: Scope

  • Proposal owners:

    • Build and test early release candidates of LLVM 20 in COPR.
    • Build and test later release candidates of LLVM 20 in koji.

  • Other developers:

    • Fix build issues found with LLVM-20 or switch their package to use the llvm19 compat libs. The LLVM team will not block Bodhi updates on dependent packages that fail to build or run with LLVM-20. 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-20 update.

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: 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 20.

:link: User Experience

:link: Dependencies

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

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)If there are major problems with LLVM 20, the compatibility package provide a way for other packages to continue using LLVM 19.
  • Contingency deadline: Final Freeze
  • Blocks release? No

:link: Documentation

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

  • llvm (now includes polly, llvm-bolt, libcxx, mlir)
  • flang
  • libclc
  • llvm-test-suite

:link: Release Notes

Last edited by @amoloney 2024-12-12T15:23:21Z

Last edited by @amoloney 2024-12-12T15:23:21Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

To clarify - does this mean that the llvm package will adopt the multi-version scheme used by Python and NodeJS (i.e. all source packages are versioned, but only one of the provides the un-versioned versions)?

4

No we won’t be doing that. We thought about it, but decided against that, so this is just a typo left over from an earlier version of the proposal. I’ve fixed it now.

1 Like
5

This change proposal has now been submitted to FESCo with ticket #3315 for voting.

To find out more, please visit our Changes Policy documentation.

6

This change has been accepted by FESCo for Fedora Linux 42. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.