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: Minimum GCC version for building glibc

On 05 Nov 2014 18:57, Joseph Myers wrote:
> On Wed, 5 Nov 2014, Mike Frysinger wrote:
> > we bump the min required version of any package for these reasons:
> >  - newer functionality is not feasible to duplicate in glibc
> >  - existing backwards compat code grows to a size that is too onerous to 
> > keep maintaining
> - There is a combinatorial explosion of possible feature combinations, so 
> to make that more maintainable it makes sense to declare old versions 
> unsupported

i lump that into my second point

> avoid even needing to think about whether a feature you're 
> using existed in some old version few people will be using.

any time you use a gcc feature you must review to see if it's supported by the 
versions we support.  bumping the min gcc version doesn't preclude that.  if 
people are using gcc 4.8 or 4.9, then they already have to go back and look at 
older ones.

> I think -Werror makes it more likely building with old versions will break 
> when they aren't actively tested.  We also now have a clear use for 
> diagnostic pragmas, new in 4.6, to allow more selective disabling of 
> particular warnings together with -Werror.

-Werror makes sense when building from git / maintainer mode, but not in any 
other scenario (such as unpacking release tarballs and running plain configure).

> > in this case, the proposal of raising gcc 4.4 to 4.7 was accompanied by "it 
> > might make implementing C11 support easier".  it seems like support for that was 
> > already posted not requiring 4.7.  so what's the reason for dropping 4.4/4.5 ?
> Having two different ways to implement atomics on the same architecture, 
> unless justified by variations in hardware support, is another 
> contribution to that combinatorial explosion of configurations.  Once 
> we're happy use of __atomic_* works well on any given architecture, I 
> think it should replace the old approach there (and so require 4.7 there) 
> rather than keeping an old and little-used alternative for building with 
> older compilers.

so your argument hinges on whether the new atomic logic should require gcc 4.7.  
that should probably shake out in the relevant threads and once it has, you've 
got a compelling reason for dropping <4.7.  but i still don't see any 
justification for, if we are retaining 4.6, why we should drop 4.4 & 4.5.

Attachment: signature.asc
Description: Digital signature

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