F40 Change Proposal: LLVM 18 (System-Wide)

LLVM 18

Wiki
Announced

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.

:link: Summary

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

:link: Owner

:link: Current status

  • Targeted release: Fedora Linux 40
  • Last updated: 2023-12-22
  • [ devel thread]
  • FESCo issue:
  • Tracker bug:
  • Release notes tracker:

:link: 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: 2064052 – debugedit error with clang DWARF5: Unknown DWARF DW_FORM_0x25 (DW_FORM_strx1)
  • 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.

:link: LLVM Build Schedule

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

:link: 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 f39 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 f39 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 f39 side-tag in Koji
  9. Push F39 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.

:link: Feedback

:link: Benefit to Fedora

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

:link: 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.
  • Release engineering: #11845

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

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

  • Alignment with Community Initiatives:

:link: Upgrade/compatibility impact

This change should not impact upgrades.

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

:link: User Experience

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

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

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

:link: Release Notes

I am maintaining intel-cm-compiler which is using llvm 8.0 in the latest tagged release, and then there is a branch that’s being developed which support llvm11. I’ll try to give that a shot, but in the best case, I’ll need llvm11.

That package by itself is leaf at the moment, but would be needed for (build time only) part of intel-media-driver-free (Tree - rpms/intel-media-driver-free - src.fedoraproject.org) in the future. And this package is now included in the default install set on bunch of our desktop deliverables via the multimedia package group.

Hi, just a gentle reminder to please not leave clazy out of the rebuilding frenzy. It always seems to need a rebuild to work with every new Clang major version.

(And sometimes takes a bit of finessing to arrive at that “works with” state, because its development tends to lag behind the Clang release schedule a bit.)

Thanks!

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

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

The wiki version has:

“Build LLVM 18.0.0-rc1 into a f49 side-tag in Koji.” I think you mean f40?

and the version posted here lists ‘f39 side tag’ ?

For the rc3 version (as a freeze exception to beta freeze), would that include rebuilds with it? Or just llvm itself with things already built with the previous version staying that way? Perhaps I missed that or it could be clarified in the proposal?

It should be f40. There some typos in the original wiki page that were fixed after this thread was created.

It depends. There a few packages that must be rebuilt, so those will be in the side-tag. For other packages where rebuilding is optional, if a package maintainer wants to rebuild their package with LLVM18, they have the option of adding it into the side-tag.

PR for clazy: PR#7: Rebuild for clang 18 - rpms/clazy - src.fedoraproject.org