Re: GCC vs GLIBC: why this stance, Drepper ?!?

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

On Sat, Jun 30, 2001 at 10:13:55AM +0200, Paolo Carlini wrote:
> Hi all,
> 
> >> I think libgcc_s.so.1 vs. GLIBC needs to be resolved, see my mail in
> >> `GCC 3.0 and GLIBC don't work together' thread on libc-alpha.
> >> I think glibc 2.2.4 should be compilable by GCC 3.0 now when it is
> released.
> >
> >I don't see this as a requirement.  In fact, I have no interest to
> >introduce such major changes.
> 
> For me this is a stance utterly incomprehensible, to say the less
> (biting my tongue)

You have to understand one thing, glibc and gcc are totally different
packages. The glibc and gcc developers have different views on roles
glibc and gcc played on a Linux/GNU system. What does that mean?

Glibc is a system package for Linux/GNU systems. That means it has
to work with every single binary on Linux/GNU systems. We are doing
our best to provice backward binary compatibility. We are very careful
about it. We don't encourage random users to build/install a new glibc
unless they know what they are doing. We recommend people get the
glibc upgrade from their distribution vendors.

Here comes gcc. Most of gcc developers don't think gcc is a system
compiler which should only come from the system vendor. To be qualified
as a system compiler, a system vendor has to verify it is compatible
with every single package on the system. It is not a simple task. I
don't think gcc releases from the FSF has ever gone through the
process. It was ok before since the new gcc didn't introduce anything
which will affect the binaries come with the system. Now we have
gcc 3.0. It has libgcc_s.so. That means all a new gcc 3.0 installation
a sudden will affect every single system binary if glibc is compiled
with gcc 3.0 or the whole system is compiled with gcc 3.0. In the
former case, libc.so is linked against libgcc_s.so and every binary
uses libc.so. Do you believe the glibc developers and the Linux/GNU
distribution vendors can/will support that? The problem is now because
of libgcc_s.so, gcc 3.0 becomes a system library. It has to be treated
similarly like glibc. To put it another way, libgcc_s.so has to be
treated like libc.so. That is installing gcc 3.0 shouldn't override
the system library, libgcc_s.so in thise case, one way or the other.

I believe we can work it out between gcc and glibc developers. But we 
first have to acknowledge that libgcc_s.so may be a serious problem on
systems where gcc is used as a system compiler. So far, I haven't seen
any signs that gcc developers have realized it. At lease, if gcc
developers can't understand the full impact of libgcc_s.so, they should
take the glibc developers's word for it. Without the cooperation
between gcc and glibc developers, I don't think we can avoid a big
mess ahead. Based on this, I think Ulrich is right not to recommend
gcc 3.0 for the time being. But we have to find a solution for this
serious problem.


H.J.