From Fedora Project Wiki
< Changes
(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...") |
(Updated all sections with valid text.) |
||
| Line 36: | Line 36: | ||
This should link to your home wiki page so we know who you are. | This should link to your home wiki page so we know who you are. | ||
--> | --> | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: carlos@redhat.com | * Name: [[User:codonell|Carlos O'Donell]], [[User:law|Jeff Law]] | ||
* Email: carlos@redhat.com, law@redhat.com | |||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
| 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 | The GNU Compiler Collection will be releasing version 11 containing many new features documented here: https://gcc.gnu.org/gcc-11/changes.html. We have been tracking gcc 11 development by building packages out of koji using a continuous tester. | ||
The GNU C Library version 2. | 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 == | == Benefit to Fedora == | ||
| 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 security and bug fixes from glibc upstream. | Stays up to date with latest features, improvements security and bug fixes from gcc and glibc upstream. | ||
== Scope == | == Scope == | ||
* Proposal owners: | * 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?--> | ||
* Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora | * 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.<!-- 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?--> | ||
<!-- 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/ | * Release engineering: [https://pagure.io/releng/issue/ #] <!-- 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 131: | Line 131: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
The compiler, and the the library are backwards compatible with the previous version of Fedora. | |||
We fully expect to fix all packaging changes in Fedora Rawhide | 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 == | == How To Test == | ||
| Line 152: | Line 156: | ||
3. What are the expected results of those actions? | 3. What are the expected results of those actions? | ||
--> | --> | ||
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 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. | 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. | ||
| Line 165: | Line 171: | ||
- Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system. | - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system. | ||
--> | --> | ||
Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc | Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. | ||
== Dependencies == | == Dependencies == | ||
| Line 176: | Line 182: | ||
<!-- 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: | * 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 --> | ||
<!-- 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 ABI freeze deadline of | * Contingency deadline: Upstream glibc ABI freeze deadline of 2021-02-01. <!-- 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? Yes, upgrading glibc does block the release. We should not ship without a newer 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. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * 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. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== Documentation == | == Documentation == | ||
| Line 186: | Line 192: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
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. | The glibc manual contains the documentation for the release and doesn't need any more additional work. | ||
| Line 194: | Line 202: | ||
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. | Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze. | ||
--> | --> | ||
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.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 | ||
Revision as of 05:15, 18 November 2020
GNU Toolchain update (gcc 11, glibc 2.33)
Summary
Switch the Fedora 33 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
- Name: Carlos O'Donell, Jeff Law
- Email: carlos@redhat.com, law@redhat.com
Current status
- Targeted release: Fedora 34
- Last updated: 2020-11-18
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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. We have been tracking gcc 11 development by building packages out of koji using a continuous tester.
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.
Scope
- Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...)
- 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.
- Release engineering: #
- 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 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.
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 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.
- 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.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