F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GNUToolchainF35

== Summary ==
Switch the Fedora 35 GNU Toolchain to gcc 11 (lastest point release),
binutils 2.37, and glibc 2.34.

The gcc 11 is already included in Fedora 34, but the release will be
updated to the latest point release. The glibc 2.34 change will be
tracked in this top-level GNU Toolchain system-wide update. Likewise
the binutils 2.37 release will be tracked in this top-level GNU
Toolchain system-wide update.
The gdb 10.2 is already in Fedora 34, but the release will be updated
to the latest point release.

== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: carlos(a)redhat.com


== Detailed Description ==

<!-- Expand on the summary, if appropriate.  A couple sentences
suffices to explain the goal, but the more details you can provide the
better. -->
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 has already released version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html. The latest point release for
gcc 11 will be included in Fedora 35, this will be either 11.1
(already released in April) or 11.2 (released later).

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

The GNU Binutils version 2.37 will be released near the end of July 2021;

The GNU Debugger verion 10.2 is already released.

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

The goal is to track and transition to the latest components of the
GNU Toolchain.

== 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 are stable and ready for the Fedora 35 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.  An update to GCC 11.2 would be a
minimal change with bug fixes. The binutils 2.37 update has the
broadest scope for change and generated object files should be
reviewed and failures to build analyzed.

<!-- See Toolchain example: https://pagure.io/releng/issue/9491 -->

A mass rebuild is strongly encouraged. The glibc 2.34 release merges
libpthread.so into libc.so and it would be important to remove
DT_NEEDED on libpthread.so from all distribution binaries.

* 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, the static linker and the the library are backwards
compatible with the previous version of Fedora.

Some packaging changes may be required for the glibc 2.34 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
All changes for gcc 11 will have been included in Fedora 34 alraedy.

There should be no need for any changes to accommodate the new GNU
Binutils release.

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 Binary Utilities has its own testsuite which is run during the
package build and examined by the binutils 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 due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 35 cycle. In particular the glibc merge of libpthread into libc
will remove the dependency in ELF binaries on libpthread, and that
cleanup is valuable for consistency.

== Contingency Plan ==
* Contingency mechanism: If glibc 2.34 provides too disruptive to
compiling the distribution we could revert to 2.33, but given that
Rawhide has started tracking glibc 2.34, no show-stopper problems are
expected.  At this point, we can still revert to upstream version 2.33
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-07-01.
* Blocks release? Yes, upgrading to the gcc point release blocks the
release. Yes, upgrading to binutils 2.37 blocks the release. Yes,
upgrading glibc does block the release. We should not ship without a
newer binutils 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 binutils 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 is already released. See
https://gcc.gnu.org/gcc-11/changes.html.

The GNU Binutils version 2.37 will be released in the middle of July
and release notes will be updated at that point.

The GNU C Library version 2.34 will be released at the beginning of
August 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


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Ben Cotton]

On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  == Contingency Plan ==
>  * Contingency mechanism: If glibc 2.34 provides too disruptive to
>  compiling the distribution we could revert to 2.33, but given that
>  Rawhide has started tracking glibc 2.34, no show-stopper problems are
>  expected.  At this point, we can still revert to upstream version 2.33
>  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-07-01.
>  
I notice that the listed contingency deadline is two days from now, so
it will have passed before this even makes it to FESCo for vote. Is
that date correct?

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Carlos O'Donell]

On Tue, Jun 29, 2021 at 2:14 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  >
>  > == Contingency Plan ==
>  > * Contingency mechanism: If glibc 2.34 provides too disruptive to
>  > compiling the distribution we could revert to 2.33, but given that
>  > Rawhide has started tracking glibc 2.34, no show-stopper problems are
>  > expected.  At this point, we can still revert to upstream version 2.33
>  > 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-07-01.
>  >
>  I notice that the listed contingency deadline is two days from now, so
>  it will have passed before this even makes it to FESCo for vote. Is
>  that date correct? 
The date is flexible. But undoing the ABI changes requires a mass rebuild.

Cheers,
Carlos.

[Florian Weimer]

* Carlos O'Donell:

>  On Tue, Jun 29, 2021 at 2:14 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
> >
> > On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
> > >
> > > == Contingency Plan ==
> > > * Contingency mechanism: If glibc 2.34 provides too disruptive to
> > > compiling the distribution we could revert to 2.33, but given that
> > > Rawhide has started tracking glibc 2.34, no show-stopper problems are
> > > expected.  At this point, we can still revert to upstream version 2.33
> > > 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-07-01.
> > >
> > I notice that the listed contingency deadline is two days from now, so
> > it will have passed before this even makes it to FESCo for vote. Is
> > that date correct?
>
>  The date is flexible. But undoing the ABI changes requires a mass rebuild. 
And due to the extensive nature of the ABI changes, we would need around
ten business days to create a dual-ABI glibc that supports the new
(2.34) ABI, but linking against it results in the old (2.33) ABI.

Thanks,
Florian