Update all llvm sub-projects in Fedora to version 11.
- Name: Tom Stellard
- Email: <email@example.com>
- Targeted release: Fedora 33
- Last updated: 2020-07-07
- FESCo issue: #2419
- Tracker bug: #1854440
- Release notes tracker: #521
All llvm sub-projects in Fedora will be updated to version 11, and there will be a soname version change for the llvm libraries. Compatibility packages clang10 and llvm10 will be added to ensure that packages that currently depend on clang and llvm version 10 libraries will continue to work.
Also, changing in this update is the compatibility package naming. The .0 will be dropped from the package name, so the compatibility packages will be called llvm10 and clang10 instead of llvm10.0 and clang10.0.
clang 11.0.0 will support the -fstack-clash-protection flag for the x86_64, s390x, and maybe ppc64le architectures. As part of this update, the rpmrc file in redhat-rpm-config will be modified so that -fstack-clash-protection is added to optflags when the %toolchain macro is set to clang.
Benefit to Fedora
New features and bug fixes provided by the latest version of LLVM.
- Proposal owners:
- Review existing llvm and clang compatibility packages and orphan any packages that are no longer used.
- Request a f33-llvm side-tag from Release Engineering.
- Build llvm10 and clang10 into the side-tag.
- When the upstream LLVM project releases version 11.0.0-rc1 (2020-7-15), package this and build it into the side tag.
- Write a patch for redhat-rpm-config that adds -fstack-clash-protection flag to optflags on all architectures for which clang has implemented this feature.
- Merge side-tag into rawhide prior to the f33 branch date.
- Continue packaging newer release candidates into rawhide and f33 until the final release is complete (~2020-8-26)
- Other developers:
- Maintainers of packages that depend on clang-libs or llvm-libs will need to update their spec files to depend on the clang10 and llvm10 compatibility packages if they want to rebuild their package and it does not work with LLVM 11 yet. The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 11 is added to Fedora. The compatibility packages will ensure that already built packages continue to work.
- Release engineering:  (a check of an impact with Release Engineering is needed)
- Policies and guidelines: No policies or guidelines will need to be updated as a result of this change.
- Trademark approval: N/A (not needed for this Change)
This change should not impact upgradeability.
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 11.
Users will benefit from new features and bug-fixes in the latest version of LLVM.
This change can be made without updating any other packages. However, as mention before, packages that need to use LLVM 10 will need to update their spec file on their first rebuild after this change.
- Contingency mechanism: (What to do? Who will do it?) If there are major problems with LLVM 11, the compatibility package provide a way for other packages to continue using LLVM 10. In the worst case, we could always revert LLVM back to LLVM 10, but this would only happen if their were an unprecedented amount of problems.
- Contingency deadline: Beta Freeze
- Blocks release? No
- Blocks product? None
Release notes will be added for this change.
LLVM sub-projects in Fedora have been updated to version 11: