This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum GCC version for building glibc
- From: Roland McGrath <roland at hack dot frob dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 4 Nov 2014 13:47:26 -0800 (PST)
- Subject: Re: Minimum GCC version for building glibc
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1410311352200 dot 4263 at digraph dot polyomino dot org dot uk> <20141104165815 dot GK5402 at vapier dot wh0rd dot info> <5459239B dot 4020901 at cs dot ucla dot edu>
My vote is for a minimum of at least 4.6. The main specific motivator for
4.6 in particular is "#pragma GCC diagnostic push", which we can use to
clean out the error-prone CFLAGS-foobar.c settings and start on the way
towards -Werror warning-free builds.
Previously I was hesitant about going to something newer than 4.6,
primarily just because one the main setups I use was 4.6 (Ubuntu 12.04).
But I've upgraded that system to one based on Ubuntu 14.04 (and so have all
Google employees), which has 4.8.
So I have no strong opinion between requiring 4.6 and requiring 4.7. AIUI
the significant issue is that we believe 4.7 will make the atomics cleanups
that Torvald is pursuing simpler. I don't really know how much simpler,
given that the compiler's atomics in 4.7 are still less than perfect.
Though I myself am not really using anything that doesn't have 4.8, I think
it is still too soon to require 4.8 this year. So I'd say we go definitely
to at least 4.6, and leave it up to the people who plan to put major work
into the atomics area to decide whether 4.7 is enough better to really care.
As to what we say in the installation instructions, I think we should go
both ways. That is, say "4.N or newer" (N=6 or N=7 TBD) but also say, "As
of release time, the newest GCC version verified to work is N". As an
individual release branch ages, that N might get updated, or it might be
changed to note specific known incompatibilities with a newer version (if
there's an issue we become aware of where branch maintainers decide it is
too invasive or risky to backport the changes that made the trunk cope with
the new GCC).
Thanks,
Roland