Changes/LLVM-19

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.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Guidance
For details on how to fill out this form, see the documentation.

Report issues
To report an issue with this template, file an issue in the pgm_docs repo.

LLVM 19

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.

Summary

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

Owner

• Name: Tom Stellard
• Email: <tstellar@redhat.com>

Current status

• Targeted release: <VERSION>/ Fedora Linux <VERSION>
• Last updated: 2024-05-04
• [Announced]
• [<will be assigned by the Wrangler> Discussion thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

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

• 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).

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

Scope

• Proposal owners:

• Other developers:

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

Early Testing (Optional)

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

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

N/A (not a System Wide Change)