Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 11, 2000, Ulrich Drepper <drepper@redhat.com> wrote:

> Every application will be linked against this library and therefore it
> must be available on the root filesystem where there is certainly no
> room for gcc.

Will this mean I won't ever be allowed to install another release of
GCC without rebuilding glibc?  This is insane!

> In the end you might end up to have an individual configuration for
> each arch/OS/host/target combination.

This is the only reasonable approach.  Can you think for a second of
having the SONAMEs of libgcc.so managed by people other than the
maintainers of ports?  They're the ones who can tell when
backward-compatibility is broken for a certain platform.

> I don't know how to make this clearer, libgcc.so is a system library.

Is this just because glibc gets symbols from it?

AFAIK, the main problem is with changing exception-handling
interfaces.  Does glibc actually use these functions?  Couldn't we
just arrange for glibc to not be linked with the exception-handling
part of libgcc, since any program that uses them would be linked with
libgcc anyway?

Another option: couldn't libgcc's object files just be folded into
libc.so, without creating the hassle of yet another system library?

> Besides, I have not heard a single convincing argument why libgcc.so
> should be generate as part of gcc.  What do you want to achieve?

We want to solve the very same problem you're trying to solve, but not
with a we-only-care-about-GNU/Linux-issues point of view.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me