From Fedora Project Wiki
(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...")
 
(Add trackers)
 
(32 intermediate revisions by 2 users not shown)
Line 19: Line 19:
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= Use update-alternatives for /usr/bin/cc and /usr/bin/c++ <!-- The name of your change proposal --> =
= Stop shipping individual component libraries in clang-libs package <!-- The name of your change proposal --> =


== Summary ==
== Summary ==
Line 25: Line 25:
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->


Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++ symlinks are managed by update-alternatives.
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.
 
== Owner ==
== Owner ==
<!--  
<!--  
Line 52: Line 53:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1787375 #1787375]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/426 #426]


== Detailed Description ==
== Detailed Description ==
Line 59: Line 60:
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->


The gcc package currently installs symlinks to /usr/bin/cc and /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++ respectively.  For this change, the gcc package will be modified so that update-alternatives creates and manages these symlinks.
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.[1]


In addition to modifying the gcc package, the clang package will be modified so that /usr/bin/clang and /usr/bin/clang++ can be used as alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives will have a lower priority than the gcc alternatives, so that by default, gcc will provide the /usr/bin/cc and /usr/bin/c++ implementations.
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.


The clang package currently has a run-time dependency on gcc, so this ensures that gcc will always provide the default implementation, because it's impossible to install clang without gcc.
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.


The only way users will be able to change the /usr/bin/cc or /usr/bin/c++ implementations will be by explicitly using the update-alternatives tool.
[1] https://llvm.org/docs/CMake.html


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 97: Line 98:
-->
-->


Many build systems default to using /usr/bin/cc and /usr/bin/c++ as the default C/C++ compilers.  Being able to easily swap out these implementation will provide a lot of flexibility within Fedora for doing things like:
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.
 
* Setting up alternative buildroots for testing.
* Installing a gcc wrapper script to /usr/bin/cc to help migrate packages to new compiler flags or to capture statistics about compiler usage.
* Letting users experiment easily with alternate compilers.
* Easily switch between system gcc and a development version of gcc.


== Scope ==
== Scope ==
* Proposal owners: The proposal owner will implement the necessary changes in the gcc and clang packages.
* 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.
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: The gcc maintainers will be responsible for reviewing and approving changes to the gcc package. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: The other maintainers will be responsible for reviewing and approving changes to their packages. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issues/9096] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 145: Line 143:
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


CI tests will be added to the gcc package to ensure that /usr/bin/cc and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when installed.  There will also be a CI test added to the clang package to ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when clang is installed.
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 ==
== User Experience ==
Line 159: Line 157:
-->
-->


This change will give users a much better way to experiment using other compilers for their own development.  They will be able to easily switch between different compilers without having to modify their projects build system or make non-standard changes to their Fedora system.
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 ==
== Dependencies ==
Line 166: Line 166:
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


This change has no other dependencies besides the changes to the gcc and clang packages.
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 Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) Proposal Owner will revert changes made to gcc and clang packages and rebuild.
* 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.
 
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: If the changes are not complete by 2 weeks before the mass rebuild, then we will consider postponing to the next Fedora release and back out any changes that were made. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Change Checkpoint: Completion deadline <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 191: Line 208:
-->
-->


The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by update-alternatives.  If you would like to change these symlinks to point to another compiler, like clang, for example, you can use these commands:
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.
 
`update-alternatives --set cc /usr/bin/clang`


`update-alternatives --set c++ /usr/bin/clang++`


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF32]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 15:49, 2 January 2020


Stop shipping individual component libraries in clang-libs package

Summary

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.

Owner

Current status

Detailed Description

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.[1]

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.

[1] https://llvm.org/docs/CMake.html

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.

Scope

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Stop-Shipping-Individual-Component-Libraries-In-clang-lib-Package&oldid=562375"