Require binutils 2.25 or later to build glibc

[Joseph Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com