Re: GCC-3.0.1 can't compile Glibc-2.2.4

["H . J . Lu" <hjl at lucon dot org>]

On Wed, Sep 26, 2001 at 11:24:15AM +0200, Mark Kettenis wrote:
> 
> Of course we will upgrade the code in glibc every now and then.  It's
> just that we must avoid being forced to do so just because GCC emits a

Why not? We have been updating the code in glibc for the changes in
gcc all the time. What is so different about this one?

> new DWARF2 opcode.  We must avoid the situation that we face now where
> people fear to upgrade to GCC 3 because you cannot compile glibc with
> it.

There is nothing wrong to check if a version of gcc is supported by
glibc. We have been doing that for a long time. I don't think it will
change any time soon. As long as we keep those gcc functions in glibc
up to date, I don't think it is a big issue.

> 
> Giving such a precompiled libc.so to other people is very well
> possible.  You just make sure that you'll also pass along a recent
> libgcc_s.so, if you used a GCC version that's not supported by the
> code in libc.so.  My understanding is that the modern packaging
> systems are perfectly able to cope with this.

I don't believe it will work in all cases. The basic problem is we
don't control libgcc_s.so.1 since it is not the part of glibc. The
libgcc_s.so.1 available to glibc can change at any time. We have no
idea if it is ok when we build/distribute libc.so. If we do this,
we may be open to all kinds of issuses.

In one word, I'd like to see libc.so be a self-contained library.


H.J.