This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Require binutils 2.25 or later to build glibc

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/, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]