Patchwork Require GCC 5 or later to build glibc (bug 23993)

login
register
mail settings
Submitter Joseph Myers
Date Dec. 18, 2018, 6:10 p.m.
Message ID <alpine.DEB.2.21.1812181809510.2407@digraph.polyomino.org.uk>
Download mbox | patch
Permalink /patch/30728/
State Committed
Headers show

Comments

Joseph Myers - Dec. 18, 2018, 6:10 p.m.
We know that building glibc with GCC 4.9 is broken on various
platforms (bug 23993).  As it's more than a year since we last
increased the minimum GCC version to build glibc, this patch changes
the requirement to be GCC 5 or later (indeed, based on 4.9 having been
required for building 2.26, it would be consistent in terms of timing
to require GCC 6 or later from the 2.30 release onwards).  It
deliberately just updates the configure test and corresponding
documentation, leaving removal of no-longer-needed __GNUC_PREREQ tests
for a separate patch.

In the NEWS entry, the requirement for a newer GCC version for
powerpc64le is reiterated (as in the entry for the 4.9 requirement in
2.26) to avoid suggesting the version requirement there has gone down.
(If that version goes up further as part of support for binary128 long
double, of course the wording would change at that time.)

Tested for x86_64.

2018-12-18  Joseph Myers  <joseph@codesourcery.com>

	[BZ #23993]
	* configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
	* configure: Regenerated.
	* manual/install.texi (Tools for Compilation): Update minimum GCC
	version.
	* INSTALL: Regenerated.
H.J. Lu - Dec. 18, 2018, 6:44 p.m.
On Tue, Dec 18, 2018 at 10:10 AM Joseph Myers <joseph@codesourcery.com> wrote:
>
> We know that building glibc with GCC 4.9 is broken on various
> platforms (bug 23993).  As it's more than a year since we last
> increased the minimum GCC version to build glibc, this patch changes
> the requirement to be GCC 5 or later (indeed, based on 4.9 having been
> required for building 2.26, it would be consistent in terms of timing
> to require GCC 6 or later from the 2.30 release onwards).  It
> deliberately just updates the configure test and corresponding
> documentation, leaving removal of no-longer-needed __GNUC_PREREQ tests
> for a separate patch.
>
> In the NEWS entry, the requirement for a newer GCC version for
> powerpc64le is reiterated (as in the entry for the 4.9 requirement in
> 2.26) to avoid suggesting the version requirement there has gone down.
> (If that version goes up further as part of support for binary128 long
> double, of course the wording would change at that time.)
>
> Tested for x86_64.
>
> 2018-12-18  Joseph Myers  <joseph@codesourcery.com>
>
>         [BZ #23993]
>         * configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
>         * configure: Regenerated.
>         * manual/install.texi (Tools for Compilation): Update minimum GCC
>         version.
>         * INSTALL: Regenerated.
>

LGTM.

Thanks.
Florian Weimer - Dec. 18, 2018, 6:45 p.m.
* Joseph Myers:

> 2018-12-18  Joseph Myers  <joseph@codesourcery.com>
>
> 	[BZ #23993]
> 	* configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
> 	* configure: Regenerated.
> 	* manual/install.texi (Tools for Compilation): Update minimum GCC
> 	version.
> 	* INSTALL: Regenerated.

Patch looks okay to me.

However, can we keep support/ at a GCC 4.9 level for some time?  This
will simplify backporting to glibc 2.27 and 2.28.  I expect to backport
regularly to these branches for about a year, maybe longer, particularly
for glibc 2.28.

Thanks,
Florian
Gabriel F. T. Gomes - Dec. 18, 2018, 6:54 p.m.
On Tue, 18 Dec 2018, Joseph Myers wrote:

>In the NEWS entry, the requirement for a newer GCC version for
>powerpc64le is reiterated (as in the entry for the 4.9 requirement in
>2.26) to avoid suggesting the version requirement there has gone down.

Thanks for writing this.

>Tested for x86_64.

On powerpc64le, it still complains that GCC 5 is not enough, as expected.

>2018-12-18  Joseph Myers  <joseph@codesourcery.com>
>
>	[BZ #23993]
>	* configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
>	* configure: Regenerated.
>	* manual/install.texi (Tools for Compilation): Update minimum GCC
>	version.
>	* INSTALL: Regenerated.

Looks good to me.
Carlos O'Donell - Dec. 18, 2018, 7:03 p.m.
On 12/18/18 1:45 PM, Florian Weimer wrote:
> * Joseph Myers:
> 
>> 2018-12-18  Joseph Myers  <joseph@codesourcery.com>
>>
>> 	[BZ #23993]
>> 	* configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
>> 	* configure: Regenerated.
>> 	* manual/install.texi (Tools for Compilation): Update minimum GCC
>> 	version.
>> 	* INSTALL: Regenerated.
> 
> Patch looks okay to me.
> 
> However, can we keep support/ at a GCC 4.9 level for some time?  This
> will simplify backporting to glibc 2.27 and 2.28.  I expect to backport
> regularly to these branches for about a year, maybe longer, particularly
> for glibc 2.28.

I don't object.

You are the defacto support/ subsystem maintainer, and because we want
support/ to be rebased to various branches to improve testing coverage
I think it's reasonable to request that support/ be slightly more
restrictive (restricts what features can be used) for a subset of gcc
versions e.g. continue to support gcc 4.9.
Adhemerval Zanella Netto - Dec. 18, 2018, 7:15 p.m.
On 18/12/2018 16:45, Florian Weimer wrote:
> * Joseph Myers:
> 
>> 2018-12-18  Joseph Myers  <joseph@codesourcery.com>
>>
>> 	[BZ #23993]
>> 	* configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
>> 	* configure: Regenerated.
>> 	* manual/install.texi (Tools for Compilation): Update minimum GCC
>> 	version.
>> 	* INSTALL: Regenerated.
> 
> Patch looks okay to me.
> 
> However, can we keep support/ at a GCC 4.9 level for some time?  This
> will simplify backporting to glibc 2.27 and 2.28.  I expect to backport
> regularly to these branches for about a year, maybe longer, particularly
> for glibc 2.28.
> 
> Thanks,
> Florian
> 

Wouldn't be better to focus on change toolchain requirements at the start
of release cycle?
Zack Weinberg - Dec. 18, 2018, 7:28 p.m.
On Tue, Dec 18, 2018 at 2:16 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> >> 2018-12-18  Joseph Myers  <joseph@codesourcery.com>
> >>
> >>      [BZ #23993]
> >>      * configure.ac (libc_cv_compiler_ok): Require GCC 5 or later.
>
> Wouldn't be better to focus on change toolchain requirements at the start
> of release cycle?

I think I agree with this. Why don't we wait until the branch happens
and then bump the minimum all the way up to GCC 6.2, thus eliminating
the difference between powerpc64le and the other platforms?

zw
Joseph Myers - Dec. 18, 2018, 10:40 p.m.
On Tue, 18 Dec 2018, Adhemerval Zanella wrote:

> Wouldn't be better to focus on change toolchain requirements at the start
> of release cycle?

This particular patch is recognizing a requirement that has already been 
introduced (two months ago - it evidently took a long time for it to be 
noticed) as a side effect of using atomic_load_relaxed on a pointer to 
const (I think - in turn, via how the default atomic_load_relaxed 
constructs an asm output using typeof, resulting in that asm output 
variable being const and the error quoted in the bug report).  Given that 
we have such a requirement in fact on some architectures, and given how 
long we've had 4.9 as official minimum GCC version for building glibc, it 
seemed to make more sense to make the requirement for GCC 5 an official 
one everywhere rather than trying to figure out how to get things working 
on older compilers.
Adhemerval Zanella Netto - Dec. 19, 2018, 8:54 p.m.
On 18/12/2018 20:40, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Adhemerval Zanella wrote:
> 
>> Wouldn't be better to focus on change toolchain requirements at the start
>> of release cycle?
> 
> This particular patch is recognizing a requirement that has already been 
> introduced (two months ago - it evidently took a long time for it to be 
> noticed) as a side effect of using atomic_load_relaxed on a pointer to 
> const (I think - in turn, via how the default atomic_load_relaxed 
> constructs an asm output using typeof, resulting in that asm output 
> variable being const and the error quoted in the bug report).  Given that 
> we have such a requirement in fact on some architectures, and given how 
> long we've had 4.9 as official minimum GCC version for building glibc, it 
> seemed to make more sense to make the requirement for GCC 5 an official 
> one everywhere rather than trying to figure out how to get things working 
> on older compilers.
> 

It indeed seems reasonable to change the minimum requirement for 2.28, even
more because the breakage [1] seems to affect most of the architectures. My
point is more for future changes, where I think setting the expectations
on start of release cycle might help users planning on toolchain
upgrade requirements. 

[1] https://gitlab.com/kubu93/toolchains-builder/pipelines/40259702
Joseph Myers - Dec. 19, 2018, 9:50 p.m.
On Wed, 19 Dec 2018, Adhemerval Zanella wrote:

> It indeed seems reasonable to change the minimum requirement for 2.28, even
> more because the breakage [1] seems to affect most of the architectures. My
> point is more for future changes, where I think setting the expectations
> on start of release cycle might help users planning on toolchain
> upgrade requirements. 

Does anyone have any further comments on making this change for 2.29 
(i.e., documenting the existing de facto change and applying it to all 
architectures)?
Joseph Myers - Dec. 21, 2018, 5:54 p.m.
I've now committed this patch.
Romain Naour - Dec. 22, 2018, 11:16 a.m.
Hi Joseph,

Le 21/12/2018 à 18:54, Joseph Myers a écrit :
> I've now committed this patch.
> 

Thanks for the patch.

Best regards,
Romain

Patch

diff --git a/INSTALL b/INSTALL
index 268b7d63fa..672eb40640 100644
--- a/INSTALL
+++ b/INSTALL
@@ -459,9 +459,9 @@  build the GNU C Library:
      As of relase time, GNU 'make' 4.2.1 is the newest verified to work
      to build the GNU C Library.
 
-   * GCC 4.9 or newer
+   * GCC 5 or newer
 
-     GCC 4.9 or higher is required.  In general it is recommended to use
+     GCC 5 or higher is required.  In general it is recommended to use
      the newest version of the compiler that is known to work for
      building the GNU C Library, as newer compilers usually produce
      better code.  As of release time, GCC 8.1.1 is the newest compiler
diff --git a/NEWS b/NEWS
index ae80818df4..1fbd109843 100644
--- a/NEWS
+++ b/NEWS
@@ -66,6 +66,12 @@  Changes to build and runtime requirements:
 
 * Python 3.4 or later is required to build the GNU C Library.
 
+* On most architectures, GCC 5 or later is required to build the GNU C
+  Library.  (On powerpc64le, GCC 6.2 or later is still required, as before.)
+
+  Older GCC versions and non-GNU compilers are still supported when
+  compiling programs that use the GNU C Library.
+
 Security related changes:
 
   CVE-2018-19591: A file descriptor leak in if_nametoindex can lead to a
diff --git a/configure b/configure
index 535e2f62e0..101dfddf37 100755
--- a/configure
+++ b/configure
@@ -5119,7 +5119,7 @@  int
 main ()
 {
 
-#if !defined __GNUC__ || __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 9)
+#if !defined __GNUC__ || __GNUC__ < 5
 #error insufficient compiler
 #endif
   ;
diff --git a/configure.ac b/configure.ac
index 6cc10ede98..46a74687a6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1017,7 +1017,7 @@  AC_CHECK_PROG_VER(BISON, bison, --version,
 
 AC_CACHE_CHECK([if $CC is sufficient to build libc], libc_cv_compiler_ok, [
 AC_TRY_COMPILE([], [
-#if !defined __GNUC__ || __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 9)
+#if !defined __GNUC__ || __GNUC__ < 5
 #error insufficient compiler
 #endif],
 	       [libc_cv_compiler_ok=yes],
diff --git a/manual/install.texi b/manual/install.texi
index 67e1e10e91..2a87a2725a 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -499,9 +499,9 @@  As of relase time, GNU @code{make} 4.2.1 is the newest verified to work
 to build @theglibc{}.
 
 @item
-GCC 4.9 or newer
+GCC 5 or newer
 
-GCC 4.9 or higher is required.  In general it is recommended to use
+GCC 5 or higher is required.  In general it is recommended to use
 the newest version of the compiler that is known to work for building
 @theglibc{}, as newer compilers usually produce better code.  As of
 release time, GCC 8.1.1 is the newest compiler verified to work to build