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

[Mark Mitchell <mark at codesourcery dot com>]

> It is the same thing as you are saying you can install another version
> of the system shared C library, libc.so, in /usr/local/lib and expect
> the whole machine will work reliably.

Yes, I am saying that.  Isn't that true?  I didn't think the base
system, installed by the vendor, was supposed to even know that /usr/local
exists.  Now, users who put /usr/local in their PATH/LD_LIBRARY_PATH
might get hosed -- but the system administrator shouldn't install stuff
that doesn't work.

Certainly, if the libc in /usr/local is backwards-compatible with the old
one, then this should not be an issue.  And, our promise is that libgcc
will be backwards compatible -- or we will bump the version number.  In
either case, people will be OK when they install a new compiler.

> 1. Gcc only comes from the system vendor. And
> 2. We don't care about compatibility between systems where glibc and
> gcc are system packages.

*If* the system vendor decides to combine libgcc and libc, then packages
will have different link dependencies depending on whether they were
compiled with the system vendor's compiler, or with the FSF GCC
distribution.  That's a cost/benefit for the system vendor to weigh;
it's not our problem.

I have faith in the system vendors to work out these problems.  They
are better at it than we are, and they know more about their systems
than we do.

There really is nothing magic about libgcc, as opposed to libX, or
libgtk, or whatever.  It's just a library.

The only complication is that glibc may be linked against it, which
creates issues because libc *is* magic in some ways.  So, the problem
is for the system vendors to figure out what they want to do.  They
can integrate libgcc in libc, and then things might not work with
packages compiled with FSF releases of GCC.  They can not integrate
libgcc in libc, and then they have to be careful about upgrading
things.  It's complicated, but computers are that way.

So, besides agreeing that it's complicated, which we do, what exactly do
you want us to do?  I would be happy to have patches that make it easier
for system vendors to do the things they want to do, but I will not
support patches that put us into the role of a system vendor.  We don't
have the expertise, and our goal is to support many, many systems; if
we include special magic for GNU/Linux, we should do it for other free
OS's too, and maybe non-free ones, and that places an additional burden
on us that I don't think we should bear.  As a relatively concrete
bright-line, I would not support patches that only make sense when
GCC is put in /usr; my concern includes only cases where the compiler
is put in /usr/local.

In my mind, our goal is to produce a compiler that people can build
anywhere, and that will, as much as possible, work in the same way
everywhere.  Then, the GNU/Linux integrators can tweak that default
as they wish in order to better server their users.

I speak only for myself, here, not the FSF or the SC.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com