This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Require binutils 2.25 or later to build glibc
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 26 Jun 2017 05:46:22 -0700
- Subject: Re: Require binutils 2.25 or later to build glibc
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1706202038480.3448@digraph.polyomino.org.uk>
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
--
H.J.