This is the mail archive of the
mailing list for the glibc project.
Re: Require binutils 2.25 or later to build glibc
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