This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]