Require binutils 2.25 or later to build glibc
Commit Message
This patch implements a requirement of binutils >= 2.25 (up from 2.22)
to build glibc. Tests for 2.24 or later on x86_64 and s390 are
removed. It was already the case, as indicated by buildbot results,
that 2.24 was too old for building tests for 32-bit x86 (produced
internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know
if any configure tests for binutils features are obsolete given the
increased version requirement.
Tested for x86_64.
2017-06-20 Joseph Myers <joseph@codesourcery.com>
* configure.ac (AS): Require binutils 2.25 or later.
(LD): Likewise.
* configure: Regenerated.
* sysdeps/s390/configure.ac (AS): Remove version check.
* sysdeps/s390/configure: Regenerated.
* sysdeps/x86_64/configure.ac (AS): Remove version check.
* sysdeps/x86_64/configure: Regenerated.
* manual/install.texi (Tools for Compilation): Document
requirement for binutils 2.25 or later.
* INSTALL: Regenerated.
Comments
Ping. This patch
<https://sourceware.org/ml/libc-alpha/2017-06/msg00960.html> is pending
review.
On Tue, Jun 20, 2017 at 1:45 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> This patch implements a requirement of binutils >= 2.25 (up from 2.22)
> to build glibc. Tests for 2.24 or later on x86_64 and s390 are
> removed. It was already the case, as indicated by buildbot results,
> that 2.24 was too old for building tests for 32-bit x86 (produced
> internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know
> if any configure tests for binutils features are obsolete given the
> increased version requirement.
>
> Tested for x86_64.
>
> 2017-06-20 Joseph Myers <joseph@codesourcery.com>
>
> * configure.ac (AS): Require binutils 2.25 or later.
> (LD): Likewise.
> * configure: Regenerated.
> * sysdeps/s390/configure.ac (AS): Remove version check.
> * sysdeps/s390/configure: Regenerated.
> * sysdeps/x86_64/configure.ac (AS): Remove version check.
> * sysdeps/x86_64/configure: Regenerated.
> * manual/install.texi (Tools for Compilation): Document
> requirement for binutils 2.25 or later.
> * INSTALL: Regenerated.
>
> diff --git a/configure.ac b/configure.ac
> index 16e97d3..db1ea40 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1071,14 +1071,14 @@ AC_PROG_LN_S
>
> LIBC_PROG_BINUTILS
>
> -# Accept binutils 2.22 or newer.
> +# Accept binutils 2.25 or newer.
> AC_CHECK_PROG_VER(AS, $AS, --version,
> [GNU assembler.* \([0-9]*\.[0-9.]*\)],
> - [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
> + [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
> AS=: critic_missing="$critic_missing as")
> AC_CHECK_PROG_VER(LD, $LD, --version,
> [GNU ld.* \([0-9][0-9]*\.[0-9.]*\)],
> - [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
> + [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
> LD=: critic_missing="$critic_missing ld")
>
> # These programs are version sensitive.
Should we also allow gold 1.14 or above to build glibc? After
commit 388b4f1a02f3a801965028bbfcd48d905638b797
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Fri Jun 23 14:38:46 2017 -0700
Avoid .symver on common symbols [BZ #21666]
The .symver directive on common symbol just creates a new common symbol,
not an alias and the newer assembler with the bug fix for
gold 1.14 can build glibc with a few "make check" errors:
https://sourceware.org/bugzilla/show_bug.cgi?id=21674
On 06/26/2017 02:46 PM, H.J. Lu wrote:
> Should we also allow gold 1.14 or above to build glibc? After
>
> commit 388b4f1a02f3a801965028bbfcd48d905638b797
> Author: H.J. Lu <hjl.tools@gmail.com>
> Date: Fri Jun 23 14:38:46 2017 -0700
>
> Avoid .symver on common symbols [BZ #21666]
>
> The .symver directive on common symbol just creates a new common symbol,
> not an alias and the newer assembler with the bug fix for
>
> gold 1.14 can build glibc with a few "make check" errors:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=21674
Do you know if the tests are miscompiled, or if glibc itself is broken?
In case the latter, we should back out the change to accept gold if this
cannot be fixed before the release.
Thanks,
Florian
On Mon, Jun 26, 2017 at 5:49 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/26/2017 02:46 PM, H.J. Lu wrote:
>> Should we also allow gold 1.14 or above to build glibc? After
>>
>> commit 388b4f1a02f3a801965028bbfcd48d905638b797
>> Author: H.J. Lu <hjl.tools@gmail.com>
>> Date: Fri Jun 23 14:38:46 2017 -0700
>>
>> Avoid .symver on common symbols [BZ #21666]
>>
>> The .symver directive on common symbol just creates a new common symbol,
>> not an alias and the newer assembler with the bug fix for
>>
>> gold 1.14 can build glibc with a few "make check" errors:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=21674
>
> Do you know if the tests are miscompiled, or if glibc itself is broken?
Most of tests are OK. But some tests are linked incorrectly by gold.
> In case the latter, we should back out the change to accept gold if this
> cannot be fixed before the release.
Gold isn't allowed to build glibc as of today. Because of it, no one was
aware of gold bugs exposed by "make check" in glibc.
On 06/26/2017 03:11 PM, H.J. Lu wrote:
> Most of tests are OK. But some tests are linked incorrectly by gold.
Okay, if it's just tests which are wrong, that's probably okay.
Thanks,
Florian
On Wed, 28 Jun 2017, Florian Weimer wrote:
> On 06/26/2017 03:11 PM, H.J. Lu wrote:
> > Most of tests are OK. But some tests are linked incorrectly by gold.
>
> Okay, if it's just tests which are wrong, that's probably okay.
Can someone review my actual patch to require binutils 2.25, independent
of any proposal to allow some set of versions of gold?
On 06/20/2017 10:45 PM, Joseph Myers wrote:
> This patch implements a requirement of binutils >= 2.25 (up from 2.22)
> to build glibc. Tests for 2.24 or later on x86_64 and s390 are
> removed. It was already the case, as indicated by buildbot results,
> that 2.24 was too old for building tests for 32-bit x86 (produced
> internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know
> if any configure tests for binutils features are obsolete given the
> increased version requirement.
Can we make 2.25.1 the minimum version? Then we can drop the check in
sysdeps/arm/configure.ac, too.
Thanks,
Florian
On Wed, 28 Jun 2017, Florian Weimer wrote:
> On 06/20/2017 10:45 PM, Joseph Myers wrote:
> > This patch implements a requirement of binutils >= 2.25 (up from 2.22)
> > to build glibc. Tests for 2.24 or later on x86_64 and s390 are
> > removed. It was already the case, as indicated by buildbot results,
> > that 2.24 was too old for building tests for 32-bit x86 (produced
> > internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know
> > if any configure tests for binutils features are obsolete given the
> > increased version requirement.
>
> Can we make 2.25.1 the minimum version? Then we can drop the check in
> sysdeps/arm/configure.ac, too.
I'm wary of testing for minor versions like that; it's entirely plausible
someone may have particular bug fixes from later on the release branch
without necessarily having the higher version number.
On Wed, Jun 28, 2017 at 3:30 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Wed, 28 Jun 2017, Florian Weimer wrote:
>
>> On 06/26/2017 03:11 PM, H.J. Lu wrote:
>> > Most of tests are OK. But some tests are linked incorrectly by gold.
>>
>> Okay, if it's just tests which are wrong, that's probably okay.
>
> Can someone review my actual patch to require binutils 2.25, independent
> of any proposal to allow some set of versions of gold?
>
LGTM.
Thanks.
On 06/28/2017 06:58 AM, Joseph Myers wrote:
> On Wed, 28 Jun 2017, Florian Weimer wrote:
>
>> On 06/20/2017 10:45 PM, Joseph Myers wrote:
>>> This patch implements a requirement of binutils >= 2.25 (up from 2.22)
>>> to build glibc. Tests for 2.24 or later on x86_64 and s390 are
>>> removed. It was already the case, as indicated by buildbot results,
>>> that 2.24 was too old for building tests for 32-bit x86 (produced
>>> internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know
>>> if any configure tests for binutils features are obsolete given the
>>> increased version requirement.
>>
>> Can we make 2.25.1 the minimum version? Then we can drop the check in
>> sysdeps/arm/configure.ac, too.
>
> I'm wary of testing for minor versions like that; it's entirely plausible
> someone may have particular bug fixes from later on the release branch
> without necessarily having the higher version number.
Are you suggesting you want to support a vendor "2.25" that has bug fixes
that has equivalent functionality to 2.25.1?
Why wouldn't such a vendor simply update to 2.25.1? Particularly if they
cared about ARM?
The upstream FSF versions have a very specific meaning. We should not be
confusing this with vendor branches and what they provide.
On Wed, 28 Jun 2017, Carlos O'Donell wrote:
> >> Can we make 2.25.1 the minimum version? Then we can drop the check in
> >> sysdeps/arm/configure.ac, too.
> >
> > I'm wary of testing for minor versions like that; it's entirely plausible
> > someone may have particular bug fixes from later on the release branch
> > without necessarily having the higher version number.
>
> Are you suggesting you want to support a vendor "2.25" that has bug fixes
> that has equivalent functionality to 2.25.1?
>
> Why wouldn't such a vendor simply update to 2.25.1? Particularly if they
> cared about ARM?
>
> The upstream FSF versions have a very specific meaning. We should not be
> confusing this with vendor branches and what they provide.
I'm suggesting that (a) it's normal for specific bug fixes to get
backported for GCC and binutils (and for that matter the Linux kernel), so
that the low part of the version number may not always be very meaningful
for configure tests in indicating what is or is not supported - and
sometimes a version number may be deliberately adjusted to ensure that
e.g. files are installed in the same place after an update as before (I
don't know if that's done specifically for binutils, but if you supported
people linking with a shared libbfd you might not want to change the
version number for bug fixes), and (b) we do generally hope things will
work with whatever recent-enough tools people have installed, and the
version checks are generally expected to work with such tools (modulo e.g.
the case of a warning option being backported and the __GNUC_PREREQ
conditionals for disabling it being based on the upstream version). And
(c) testing for the low part complicates the patterns used to test for
version numbers, without much corresponding benefit.
On 06/28/2017 09:29 AM, Joseph Myers wrote:
> On Wed, 28 Jun 2017, Carlos O'Donell wrote:
>
>>>> Can we make 2.25.1 the minimum version? Then we can drop the check in
>>>> sysdeps/arm/configure.ac, too.
>>>
>>> I'm wary of testing for minor versions like that; it's entirely plausible
>>> someone may have particular bug fixes from later on the release branch
>>> without necessarily having the higher version number.
>>
>> Are you suggesting you want to support a vendor "2.25" that has bug fixes
>> that has equivalent functionality to 2.25.1?
>>
>> Why wouldn't such a vendor simply update to 2.25.1? Particularly if they
>> cared about ARM?
>>
>> The upstream FSF versions have a very specific meaning. We should not be
>> confusing this with vendor branches and what they provide.
>
> I'm suggesting that (a) it's normal for specific bug fixes to get
> backported for GCC and binutils (and for that matter the Linux kernel), so
> that the low part of the version number may not always be very meaningful
> for configure tests in indicating what is or is not supported - and
> sometimes a version number may be deliberately adjusted to ensure that
> e.g. files are installed in the same place after an update as before (I
> don't know if that's done specifically for binutils, but if you supported
> people linking with a shared libbfd you might not want to change the
> version number for bug fixes), and (b) we do generally hope things will
> work with whatever recent-enough tools people have installed, and the
> version checks are generally expected to work with such tools (modulo e.g.
> the case of a warning option being backported and the __GNUC_PREREQ
> conditionals for disabling it being based on the upstream version). And
> (c) testing for the low part complicates the patterns used to test for
> version numbers, without much corresponding benefit.
I agree with (c), and I also agree that making the public statement
"We support 2.25" is the simplest message we can send.
I expect the ARM configure clenaup can happen when we eventually require
a newer version.
On 06/28/2017 03:55 PM, Carlos O'Donell wrote:
> I agree with (c), and I also agree that making the public statement
> "We support 2.25" is the simplest message we can send.
>
> I expect the ARM configure clenaup can happen when we eventually require
> a newer version.
Okay, let's do it this way (using Joseph's original patch).
Thanks,
Florian
@@ -443,7 +443,7 @@ build the GNU C Library:
Check the FAQ for any special compiler issues on particular
platforms.
- * GNU 'binutils' 2.22 or later
+ * GNU 'binutils' 2.25 or later
You must use GNU 'binutils' (as and ld) to build the GNU C Library.
No other assembler or linker has the necessary functionality at the
@@ -115,6 +115,9 @@ Version 2.26
C Library is GCC 4.9. Older GCC versions, and non-GNU compilers, can
still be used to compile programs using the GNU C Library.
+* The minimum GNU Binutils version that can be used to build this version of
+ the GNU C Library is Binutils 2.25.
+
Security related changes:
* The DNS stub resolver limits the advertised UDP buffer size to 1200 bytes,
@@ -4598,7 +4598,7 @@ $as_echo "$libc_cv_prog_ld_gnu" >&6; }
gnu_ld=$libc_cv_prog_ld_gnu
-# Accept binutils 2.22 or newer.
+# Accept binutils 2.25 or newer.
for ac_prog in $AS
do
# Extract the first word of "$ac_prog", so it can be a program name with args.
@@ -4650,7 +4650,7 @@ $as_echo_n "checking version of $AS... " >&6; }
ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$/\1/p'`
case $ac_prog_version in
'') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
- 2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*)
+ 2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*)
ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
@@ -4713,7 +4713,7 @@ $as_echo_n "checking version of $LD... " >&6; }
ac_prog_version=`$LD --version 2>&1 | sed -n 's/^.*GNU ld.* \([0-9][0-9]*\.[0-9.]*\).*$/\1/p'`
case $ac_prog_version in
'') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
- 2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*)
+ 2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*)
ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
*) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
@@ -1071,14 +1071,14 @@ AC_PROG_LN_S
LIBC_PROG_BINUTILS
-# Accept binutils 2.22 or newer.
+# Accept binutils 2.25 or newer.
AC_CHECK_PROG_VER(AS, $AS, --version,
[GNU assembler.* \([0-9]*\.[0-9.]*\)],
- [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
+ [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
AS=: critic_missing="$critic_missing as")
AC_CHECK_PROG_VER(LD, $LD, --version,
[GNU ld.* \([0-9][0-9]*\.[0-9.]*\)],
- [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
+ [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
LD=: critic_missing="$critic_missing ld")
# These programs are version sensitive.
@@ -489,7 +489,7 @@ You can use whatever compiler you like to compile programs that use
Check the FAQ for any special compiler issues on particular platforms.
@item
-GNU @code{binutils} 2.22 or later
+GNU @code{binutils} 2.25 or later
You must use GNU @code{binutils} (as and ld) to build @theglibc{}.
No other assembler or linker has the necessary functionality at the
@@ -4,71 +4,6 @@
$as_echo "#define PI_STATIC_AND_HIDDEN 1" >>confdefs.h
-for ac_prog in $AS
-do
- # Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_AS+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- if test -n "$AS"; then
- ac_cv_prog_AS="$AS" # Let the user override the test.
-else
-as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
- IFS=$as_save_IFS
- test -z "$as_dir" && as_dir=.
- for ac_exec_ext in '' $ac_executable_extensions; do
- if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
- ac_cv_prog_AS="$ac_prog"
- $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
- break 2
- fi
-done
- done
-IFS=$as_save_IFS
-
-fi
-fi
-AS=$ac_cv_prog_AS
-if test -n "$AS"; then
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AS" >&5
-$as_echo "$AS" >&6; }
-else
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
- test -n "$AS" && break
-done
-
-if test -z "$AS"; then
- ac_verc_fail=yes
-else
- # Found it, now check the version.
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking version of $AS" >&5
-$as_echo_n "checking version of $AS... " >&6; }
- ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$/\1/p'`
- case $ac_prog_version in
- '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
- 2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*)
- ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
- *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
-
- esac
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_prog_version" >&5
-$as_echo "$ac_prog_version" >&6; }
-fi
-if test $ac_verc_fail = yes; then
- critic_missing="$critic_missing The program AS is required in version >= 2.24 for target S390."
-fi
-
-
-
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for __builtin_tbegin" >&5
$as_echo_n "checking for __builtin_tbegin... " >&6; }
if ${libc_cv_gcc_builtin_tbegin+:} false; then :
@@ -5,12 +5,6 @@ dnl It is always possible to access static and hidden symbols in an
dnl position independent way.
AC_DEFINE(PI_STATIC_AND_HIDDEN)
-dnl Accept as 2.24 or newer.
-AC_CHECK_PROG_VER(AS, $AS, --version,
- [GNU assembler.* \([0-9]*\.[0-9.]*\)],
- [2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], critic_missing="$critic_missing The program AS is required in version >= 2.24 for target S390.")
-
-
AC_CACHE_CHECK(for __builtin_tbegin, libc_cv_gcc_builtin_tbegin, [dnl
cat > conftest.c <<\EOF
#include <htmintrin.h>
@@ -1,70 +1,6 @@
# This file is generated from configure.ac by Autoconf. DO NOT EDIT!
# Local configure fragment for sysdeps/x86_64.
-for ac_prog in $AS
-do
- # Extract the first word of "$ac_prog", so it can be a program name with args.
-set dummy $ac_prog; ac_word=$2
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
-$as_echo_n "checking for $ac_word... " >&6; }
-if ${ac_cv_prog_AS+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- if test -n "$AS"; then
- ac_cv_prog_AS="$AS" # Let the user override the test.
-else
-as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
- IFS=$as_save_IFS
- test -z "$as_dir" && as_dir=.
- for ac_exec_ext in '' $ac_executable_extensions; do
- if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then
- ac_cv_prog_AS="$ac_prog"
- $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5
- break 2
- fi
-done
- done
-IFS=$as_save_IFS
-
-fi
-fi
-AS=$ac_cv_prog_AS
-if test -n "$AS"; then
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AS" >&5
-$as_echo "$AS" >&6; }
-else
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5
-$as_echo "no" >&6; }
-fi
-
-
- test -n "$AS" && break
-done
-
-if test -z "$AS"; then
- ac_verc_fail=yes
-else
- # Found it, now check the version.
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking version of $AS" >&5
-$as_echo_n "checking version of $AS... " >&6; }
- ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$/\1/p'`
- case $ac_prog_version in
- '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;;
- 2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*)
- ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;;
- *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;;
-
- esac
- { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_prog_version" >&5
-$as_echo "$ac_prog_version" >&6; }
-fi
-if test $ac_verc_fail = yes; then
- critic_missing="$critic_missing The program AS is required in version >= 2.24 for target x86_64."
-fi
-
-
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for AVX512DQ support in assembler" >&5
$as_echo_n "checking for AVX512DQ support in assembler... " >&6; }
if ${libc_cv_asm_avx512dq+:} false; then :
@@ -1,12 +1,6 @@
GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory.
# Local configure fragment for sysdeps/x86_64.
-dnl Accept as 2.24 or newer for AVX512 load and store.
-AC_CHECK_PROG_VER(AS, $AS, --version,
- [GNU assembler.* \([0-9]*\.[0-9.]*\)],
- [2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*],
- critic_missing="$critic_missing The program AS is required in version >= 2.24 for target x86_64.")
-
dnl Check if asm supports AVX512DQ.
AC_CACHE_CHECK(for AVX512DQ support in assembler, libc_cv_asm_avx512dq, [dnl
cat > conftest.s <<\EOF