From Fedora Project Wiki
m (Add trackers)
 
(6 intermediate revisions by 3 users not shown)
Line 24: Line 24:
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
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?". -->
Switch the Fedora 33 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.
Switch the Fedora 34 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.


The binutils 2.35 change is being tracked here:
The binutils 2.35 change is being tracked here:
Line 48: Line 48:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF34]]
<!-- 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 -->
Line 67: Line 67:
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
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2507 #2507]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1906093 #1906093]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/612 #612]


== Detailed Description ==
== Detailed Description ==
Line 76: Line 76:
The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities make up the core part of the GNU Toolchain and it is useful to transition these components as a complete implementation when making a new release of Fedora.
The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities make up the core part of the GNU Toolchain and it is useful to transition these components as a complete implementation when making a new release of Fedora.


The GNU Compiler Collection will be releasing version 11 containing many new features documented here: https://gcc.gnu.org/gcc-11/changes.html.  Historically pre-releases of GCC drop into Fedora in Jan/Feb just prior to the mass rebuild.  The major change this year is the desire to drop in snapshots of GCC 11 into rawhide starting in November with updates throughout the Fedora 34 release process as needed.
The GNU Compiler Collection will be releasing version 11 containing many new features documented here: https://gcc.gnu.org/gcc-11/changes.html.  Historically pre-releases of GCC drop into Fedora in Jan/Feb just prior to the mass rebuild.  The major process change this year is the desire to drop in snapshots of GCC 11 into rawhide starting in November with updates throughout the Fedora 34 release process as needed.


The GNU C Library version 2.33 will be released at the beginning of February 2020; we have started closely tracking the glibc 2.33 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 34 will branch after the glibc 2.33 upstream release. However, the mass rebuild schedule means Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes.
The GNU C Library version 2.33 will be released at the beginning of February 2020; we have started closely tracking the glibc 2.33 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 34 will branch after the glibc 2.33 upstream release. However, the mass rebuild schedule means Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes.
Line 109: Line 109:
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->
-->
Stays up to date with latest features, improvements security and bug fixes from gcc and glibc upstream. The change to drop GCC 11 snapshots into rawhide earlier is meant to start more wide scale testing of GCC earlier.  This means that package maintainers will not be faced with a onslaught on FTBFS issues in Feb/Mar and the GCC maintainers will not be as stressed trying to fix all Fedora related issues in a short time frame as well.
Stays up to date with latest features, improvements security and bug fixes from gcc and glibc upstream.
 
The change to drop GCC 11 snapshots into rawhide earlier is meant to start more wide scale testing of GCC earlier.  This means that package maintainers will not be faced with a onslaught on FTBFS issues in Feb/Mar and the GCC maintainers will not be as stressed trying to fix all Fedora related issues in a short time frame as well.


== Scope ==
== Scope ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...)
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...)
<!-- 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?-->
The gcc and glibc teams will need to move their respective upstream projects to a releasable state.  For GCC this includes correctly building Fedora rawhide.


* Other developers: Developers need to ensure that gcc, binutils, and glibc in rawhide is stable and ready for the Fedora 34 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files.  GCC is currently being tested weekly against Fedora rawhide and fixes for issues discovered are continually dropping into rawhide to minimize the impact on package maintainers.  However, we fully expect some issues to arise, particularly as the GCC team's tests are limited to x86_64.
* Other developers: Developers need to ensure that gcc, binutils, and glibc in rawhide is stable and ready for the Fedora 34 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files.  GCC is currently being tested weekly against Fedora rawhide and fixes for issues discovered are continually dropping into rawhide to minimize the impact on package maintainers.  However, we fully expect some issues to arise, particularly as the GCC team's tests are limited to x86_64.
Line 121: Line 124:


<!-- See Toolchain example: https://pagure.io/releng/issue/9491 -->
<!-- See Toolchain example: https://pagure.io/releng/issue/9491 -->
* Release engineering:  [https://pagure.io/releng/issue/ #]  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering:  [https://pagure.io/releng/issue/9858 9858]  <!-- 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 -->
A mass rebuild is strongly encouraged.


* Policies and guidelines: The policies and guidelines do not need to be updated. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: The policies and guidelines do not need to be updated. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 181: Line 185:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
All packages do not need to be rebuilt.
All packages do not need to be rebuilt due to backwards compatibility.  However, it is advantageous if a mass rebuild is performed during the Fedora 34 cycle.


== 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: If gcc 11 proves too disruptive to compiling the distribution, which is not expected, we could revert to gcc 10 for the release. If glibc 2.33 provides too disruptive to compiling the distribution we could rever to 2.32, but given that Rawhide has started tracking glibc 2.33, no show-stopper problems are expected.  At this point, we can still revert to upstream version 2.32 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API.  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: If gcc 11 proves too disruptive to compiling the distribution, which is not expected, we could revert to gcc 10 for the release. If glibc 2.33 provides too disruptive to compiling the distribution we could revert to 2.32, but given that Rawhide has started tracking glibc 2.33, no show-stopper problems are expected.  At this point, we can still revert to upstream version 2.32 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API.  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- 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: Upstream glibc ABI freeze deadline of 2021-02-01. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: Upstream glibc ABI freeze deadline of 2021-02-01. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 209: Line 213:
The GNU Compiler Collection version 11 will be released shortly. See https://gcc.gnu.org/gcc-11/changes.html.
The GNU Compiler Collection version 11 will be released shortly. See https://gcc.gnu.org/gcc-11/changes.html.


The GNU C Library version 2.32 will be released at the beginning of August 2020. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
The GNU C Library version 2.33 will be released at the beginning of February 2021. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD

Latest revision as of 16:54, 9 December 2020


GNU Toolchain update (gcc 11, glibc 2.33)

Summary

Switch the Fedora 34 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.

The binutils 2.35 change is being tracked here: https://fedoraproject.org/wiki/Changes/BINUTILS235

The gcc 11 and glibc 2.33 change will be tracked in this top-level GNU Toolchain system-wide update.

Owner

Current status

Detailed Description

The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities make up the core part of the GNU Toolchain and it is useful to transition these components as a complete implementation when making a new release of Fedora.

The GNU Compiler Collection will be releasing version 11 containing many new features documented here: https://gcc.gnu.org/gcc-11/changes.html. Historically pre-releases of GCC drop into Fedora in Jan/Feb just prior to the mass rebuild. The major process change this year is the desire to drop in snapshots of GCC 11 into rawhide starting in November with updates throughout the Fedora 34 release process as needed.

The GNU C Library version 2.33 will be released at the beginning of February 2020; we have started closely tracking the glibc 2.33 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 34 will branch after the glibc 2.33 upstream release. However, the mass rebuild schedule means Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes.

Benefit to Fedora

Stays up to date with latest features, improvements security and bug fixes from gcc and glibc upstream.

The change to drop GCC 11 snapshots into rawhide earlier is meant to start more wide scale testing of GCC earlier. This means that package maintainers will not be faced with a onslaught on FTBFS issues in Feb/Mar and the GCC maintainers will not be as stressed trying to fix all Fedora related issues in a short time frame as well.

Scope

  • Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...)

The gcc and glibc teams will need to move their respective upstream projects to a releasable state. For GCC this includes correctly building Fedora rawhide.

  • Other developers: Developers need to ensure that gcc, binutils, and glibc in rawhide is stable and ready for the Fedora 34 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. GCC is currently being tested weekly against Fedora rawhide and fixes for issues discovered are continually dropping into rawhide to minimize the impact on package maintainers. However, we fully expect some issues to arise, particularly as the GCC team's tests are limited to x86_64.


  • Release engineering: 9858

A mass rebuild is strongly encouraged.

  • Policies and guidelines: The policies and guidelines do not need to be updated.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The compiler, and the the library are backwards compatible with the previous version of Fedora.

Some packaging changes may be required for the glibc 2.33 rebase: https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes

Some source changes may be required for gcc 11 rebase: https://gcc.gnu.org/gcc-11/changes.html

We fully expect to fix all packaging changes in Fedora Rawhide without impact to the release.

How To Test

The GNU C compiler collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded. The GCC team also is also doing continuous testing of GCC 11 snapshots against Fedora rawhide to identify and resolve issues prior to new versions of GCC landing in rawhide. This work will continue, particularly in Nov, Dec, Jan and Feb and we will use it to help guide decisions about snapshots are stable enough to not cause major Fedora rawhide disruptions. We expect that by March the pace of updates will reduce significantly.

The GCC team will likely need some help addressing some of the new diagnostics that require package specific knowledge to determine if the code is valid or not. This is not new, but the timing will shift to earlier points in the Fedora release cycle.

The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future may also run the microbenchmark to look for performance regressions.

User Experience

Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc.

Dependencies

All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 34 cycle.

Contingency Plan

  • Contingency mechanism: If gcc 11 proves too disruptive to compiling the distribution, which is not expected, we could revert to gcc 10 for the release. If glibc 2.33 provides too disruptive to compiling the distribution we could revert to 2.32, but given that Rawhide has started tracking glibc 2.33, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.32 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API.
  • Contingency deadline: Upstream glibc ABI freeze deadline of 2021-02-01.
  • Blocks release? Yes, upgrading to gcc 11 blocks the release. Yes, upgrading glibc does block the release. We should not ship without a newer gcc and glibc, there will be gcc and language features that depend on glibc being upgraded. Thus without the upgrade some features will be disabled or fall back to less optimal implementations.

Documentation

The gcc manual contains the documentation for the release and doesn't need any more additional work.

The glibc manual contains the documentation for the release and doesn't need any more additional work.

Release Notes

The GNU Compiler Collection version 11 will be released shortly. See https://gcc.gnu.org/gcc-11/changes.html.

The GNU C Library version 2.33 will be released at the beginning of February 2021. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD