Changes/LLVM-10

LLVM 10

Summary

Update all llvm sub-projects in Fedora to version 10.

Owner

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

Current status

• Targeted release: Fedora 32
• Last updated: 2019-12-12
• 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 10. Compatibility packages clang9.0 and llvm9.0 will be added to ensure that packages that currently depend on clang and llvm version 9 libraries will continue to work.

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.
  • Request a f32-llvm side-tag from Release Engineering.
  • Build llvm9.0 and clang9.0 into the side-tag.
  • When the upstream LLVM project releases version 10.0.0-rc1 (2020-1-15), package this and build it into the side tag.
  • Merge side-tag into rawhide prior to the f32 branch date.
  • Continue packaging newer release candidates into rawhide and f32 until the final release is complete (~2020-2-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 clang9.0 and llvm9.0 if they want to rebuild their package and it does not work with llvm 10 yet. (The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 10 is added to Fedora. The compatibility packages will ensure that already built packages continue to work.

• Release engineering: [1] (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)

Upgrade/compatibility impact

This change should not impact upgradeability.

How To Test

This can be tested using existing CI tests or tests in the %check section of spec files. The changes should not be visible to end users so tests should behave exactly as they did before the change.

User Experience

End users that develop applications using the clang libraries will need to update their applications to use libclang-cpp.so instead of the individual component libraries if they want to use libraries shipped with Fedora. This may be inconvenient, but we don't want users to continue using a configuration that is not supported by the upstream project. Once this change is made though, the applications will see the same benefits mentioned in the "Benefits to Fedora" section.

End users using Fedora packages that depend on clang libraries will not need to do anything different.

Dependencies

The following packages depend on clang-libs and will need to be updated:

• bcc
• bpftrace
• castxml
• ccls
• clazy
• gnome-builder
• ispc
• kdevelop
• lldb
• mesa
• pocl
• qt-creator
• qt5-doctools
• shiboken2
• tinygo

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) If we are unable to migrate all dependent packages in time, then the proposal owner will postpone the final step of passing -DBUILD_SHARED_LIBS=OFF to cmake when configuring clang until a future Fedora release. In this case, packages that have already been migrated will continue to work, since libclang-cpp.so is already included in the clang-libs package.

• Contingency deadline: Change Checkpoint: Completion deadline
• Blocks release? No
• Blocks product? None

Documentation

Release notes will be added for this change.

Release Notes

The individual component libraries (e.g. libclangBasic.so, libclangAST.so, etc.) have been removed from the clang-libs packages. Developers who want to link their application against the clang libraries should link against libclang-cpp.so instead.