Stop shipping individual component libraries in clang-libs package
Remove the individual component libraries (e.g. libclangBasic.so, libclangAST.so, etc.) from the clang-libs package. Packages that depend on the clang libraries should instead link against libclang-cpp.so.
- Name: Tom Stellard
- Email: <email@example.com>
- Targeted release: Fedora 32
- Last updated: 2020-01-02
- Tracker bug: #1787375
- Release notes tracker: #426
The individual component libraries will be removed from the clang-libs package in favor of libclang-cpp.so (which is already present in clang-libs). The component shared libraries enabled by the BUILD_SHARED=ON CMake option are not supported as a distribution configuration by the upstream project and only recommended for use by clang developers.
The libclang-cpp.so shared object was added in clang 9.0 and now gives us an alternative shared library option that is supported by the upstream project and makes it possible for Fedora packages to stop using the component libraries.
This change will be made only in clang 10 and newer. The clang9.0 and older compatibility packages will keep the component libraries until those packages are retired.
Benefit to Fedora
We will improve stability in Fedora by packaging a build configuration that is supported by the upstream project. In addition, libclang-cpp.so will provide more LTO optimization opportunities than the component libraries if LTO is enabled in Fedora builds. Also, in order to access the clang API with the component libraries, an application might need to link with up to 37 different shared libraries, replacing these with a single shared library will help improve application start-up times.
- Proposal owners:
- The proposal owner will ensure that that all packages that depend on clang-libs are updated to use libclang-cpp.so.
- Once all dependent packages have been migrated, the clang package will be updated to pass -DBUILD_SHARED=OFF to cmake when configuring.
- Other developers: The other maintainers will be responsible for reviewing and approving changes to their packages.
- 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
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.
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.
The following packages depend on clang-libs and will need to be updated:
- 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
Release notes will be added for this change.
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.