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

[Mark Mitchell <mark at codesourcery dot com>]

I will not encourage anyone to do anything about these issues unless
everyone takes a very, very civil tone about it.  No sarcasm, no insults,
no implied "you cannot know what you are doing", no "do you seriously
think".  Flamewars and insults, whoever the source, will be ignored. 
Period.

We introduced libgcc for very good reasons, and those reasons are
documented in these archives.  We understand that by doing so we have
made a promise not to break the binary interface to libgcc.  We will
do our best to keep that promise, and we will certainly fix any breakage
that is reported.

Your `./configure' example is not an issue, as has been discussed before,
since that only affects people who use --prefix=/usr.  Otherwise, the
new libgcc will not be used, unless you have an explicitly set 
LD_LIBRARY_PATH, which, presumably, key system processes run as root,
do not.

The key problem, as discussed before, and as you pointed out in your
message, is that GCC is both a system compiler (on some systems) and
not (on other systems).  It is the job of the system integrator to take
GCC and make it work well in those situations where it is a system
compiler.  Our job is to make that possible.

It may well be that folding libgcc into glibc, on GNU/Linux systems, is the 
right thing.  This is what almost all other OS vendors do with their
equivalent libraries.  This is not a hard job for a system integrator
to do.  If the GNU/Linux folks think this is a good idea, I would
encourage patches that make that easier, by for example, giving a way
to configure so that the default specs do not contain references to
libgcc_s.so.  Fundamentally, however, it is our job to faciliate good
practice by system vendors, but not to implement it.  Suffice it to say
that all of the system vendors already maintain much more substantial
patches to many parts of the system than would be required to implement
*whatever* solution they require to solve this problem.

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