This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: requiring GCC >= 4.7 to build glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 5 Oct 2015 20:34:15 +0000
- Subject: Re: RFC: requiring GCC >= 4.7 to build glibc
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1508201344140 dot 30940 at digraph dot polyomino dot org dot uk> <5612CBD3 dot 9040601 at redhat dot com>
On Mon, 5 Oct 2015, Florian Weimer wrote:
> On 08/20/2015 03:51 PM, Joseph Myers wrote:
> > For glibc 2.21 we increased the minimum GCC version for building glibc to
> > 4.6. There's one major GCC release a year, so the correspondingly old
> > version for glibc 2.23 would be GCC 4.7. What do people think about
> > increasing the minimum version requirement?
>
> Somewhat related: I find it rather odd that we are very conservative
> when it comes to pushing the minimum requirement for GCC, but are very
> aggressively requiring newer binutils versions. As a result, it is
> quite difficult to find stock systems which can build glibc and actually
> have older GCC versions.
As I said in <https://sourceware.org/ml/libc-alpha/2015-08/msg00917.html>,
I think a move to a binutils 2.23 version requirement for glibc 2.23 would
be reasonable. GCC 4.7 and binutils 2.23 are of similar vintage (both
released in 2012), as are the current requirements of 4.6 and 2.22, so I
don't see a substantial difference there (the binutils release is about
seven months newer). I didn't propose a binutils version requirement
increase simply because I don't have list of cleanups to hand that it
would enable, whereas I could easily do a ten-patch (approximately) series
of cleanups facilitated by an increase to the GCC version requirement
without needing to hunt through configure scripts for obsolete configure
tests.
Are you saying that binutils 2.22 support is in fact already broken (which
is something I'd take as evidence to justify such a move - that people are
actually using features in glibc that 2.22 doesn't have)?
--
Joseph S. Myers
joseph@codesourcery.com