This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- From: "H . J . Lu" <hjl at valinux dot com>
- Date: Tue, 11 Jul 2000 13:43:37 -0700
- Cc: Ulrich Drepper <drepper at cygnus dot com>, law at cygnus dot com,Mark Kettenis <kettenis at wins dot uva dot nl>, rth at twiddle dot net,libc-hacker at sourceware dot cygnus dot com, gcc at gcc dot gnu dot org
- References: <5003.963333245@upchuck> <m31z10k1h6.fsf@otr.mynet.cygnus.com> <or4s5w5rwe.fsf@guarana.lsd.ic.unicamp.br>
On Tue, Jul 11, 2000 at 05:33:05PM -0300, Alexandre Oliva wrote:
> 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!
No. That is why Ulrich suggested it be a standalone package.
>
> > 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.
People who define the ABI don't necessarily to have to define the
SONAME or maintain the shared library. You can not just simply break
the backward-compatibility for libgcc.so since it will be a system
library. It has to be controlled by the system.
>
> > I don't know how to make this clearer, libgcc.so is a system library.
>
> Is this just because glibc gets symbols from it?
Yes.
>
> AFAIK, the main problem is with changing exception-handling
> interfaces. Does glibc actually use these functions? Couldn't we
glibc wants to use it in the future.
> 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?
No.
>
> Another option: couldn't libgcc's object files just be folded into
> libc.so, without creating the hassle of yet another system library?
That is what we do today and it doesn't work very well. If you don't
know why, ......
>
> > 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.
>
As far as I know, only systems, where the shared C library uses gcc's
frame based exception, has this problem. Could you please name the
other systems?
--
H.J. Lu (hjl@gnu.org)