Re: typeof woes in symbol renaming, or glibc x gcc

[Alexandre Oliva <aoliva at redhat dot com>]

On Aug 29, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

>> GNU/Linux vendors haven't got a choice.

> Sure they do.

> I understand how new stuff in GCC gets used in glibc, and how then
> *if* you commit to the latest version of glibc you need changes to
> GCC that aren't there in a released version.

> Note the *if*.  There's no rule that says that you have to ship glibc
> 2.3 just because it is out.

It's not that simple.  We use the same compiler to build the entire
distro.  I doubt any single version of GCC would be able to build all
packages on all architectures we support.  Even if the GCC release
schedule happened to coincide with ours (which would surely be fun for
conspiracy theorists :-), or perhaps with every other GNU/Linux
vendor's, we'd still be in a difficult position because such schedules
aren't public and, even if they were, some distros include more
packages than others, or at least different versions of the same
packages, or target fewer architectures.  So, those who happened to
use only packages that already build fine could press the release
manager to put the release out, so that they could release their
product based on it.

I.e., it would be a nightmare you probably wouldn't want to be in :-)
Better leave each GNU/Linux vendor support the compiler the compiler
they ship.

> I'm sure there are very good reasons for wanting the lastest glibc, but
> I would be happier if the distributors had picked the glibc version
> they wanted, figured out what stuff needed to be in GCC to accomplish
> that, and had gotten that into a major version of GCC, and then had used
> that GCC.

This is exactly what we did.  Except that the changes in glibc that
exposed bugs in GCC 3.2 in some platforms hadn't been made yet, and
now that GCC 3.2 is already out, it's impossible to go back and fix
it, and glibc developers are adamant that they won't go out of their
way because of compiler bugs.  If the fix for a bug in glibc happens
to break other software, that's too bad, but the bug has to be fixed.
To wit, check out the current CVS tree of glibc, and try to build GCC
3.2 (or even GCC mainline) with it.  libstdc++-v3 won't build because
of a change in ctype.h required by changes in the implementation of
locale.  This change went in in the last 24 hours.  How could we have
fixed GCC 3.2 to cope with it?  Or are we saying we shouldn't have
decided we wanted to track the glibc 2.3 code base for our next
release, and instead have shorter ABI-breaking cycles, since the next
release is based on GCC 3.2, and we'd need another one whenever we
switched to glibc 2.3?  Historically, we've changed compiler and glibc
major releases at the same time.

> The problem is that pulling stuff into minor releases of GCC because
> its needed in glibc puts us in a difficult position.  If those things
> are at all risky-looking, we risk destabilizing the compiler for all
> users, including those who aren't GNU/Linux users.

I agree and understand.  You, as the Release Manager of GCC for the
Free Software foundation, is not required to accept such changes.
You're also free to get in touch with the maintainers of the GNU C
library to ask them to avoid making changes that would expose problems
in GCC and force vendors of systems based on the GNU C library to
either (i) integrate patches despite the GCC RM's ruling, (ii) revert
a patch in glibc despite its maintainers' ruling, (iii) wait until a
new version of GCC goes out that fixes the problem (and probably
introduces others :-) or (iv) stick to an earlier version of glibc.

Since (iii) is too risky and (iv) is undesirable, we often found
ourselves between (i) and (ii).  Since fixing a bug in the compiler is
often better than turning our copy of the C library incompatible with
everybody else's, it's not too hard to realize we often end up picking
(i).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer