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

  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.
  

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.
  

* 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
  

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.
  

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.
  

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?
  

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
  

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.
  

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
  

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)?
  

I've now committed this patch.
  

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