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

[Geoff Keating <geoffk at cygnus dot com>]

> From: Ulrich Drepper <drepper@redhat.com>
> Date: 11 Jul 2000 09:21:23 -0700

> > what libraries have been built (do you really want to spread
> > multilib knowledge any further than it's already spread)?
> 
> We are not talked about some stupid embedded systems with multilib
> needs.  We are talking about systems where we need binary
> compatibility because of shared libraries.

Actually, libgcc.so needs to be built with the same multilibs as
glibc, not all the ones that gcc supports.  For example, on
powerpc-linux we don't need a -msoft-float libgcc.so because it would
be useless.  So this is knowledge that is presently only held by
glibc.

> If you want to extend this to other, e.g., embedded systems, for
> whatever reason you can device another scheme since it will not have
> the same requirement.

... and even for hosted architectures it's tricky.  For instance, on
AIX we'll have to use the AIX mechanism for putting 32-bit and 64-bit
objects in the same shared library, which will be completely different
to anything done elsewhere.  For HPUX, there will be another
completely different thing to support o32/n32/n64 (or whatever it is).

> > I do not see what we gain by moving the creation of libgcc.so to another
> > package other than unnecessary complexity.  I do not see that it simplifies
> > things.
> 
> Then you really misunderstood the motifs.
> 
> > But that can be done in gcc too
> 
> I don't doubt this but will you have the manpower to keep this up?
> Because this is supposed to run on Linux where we use all kinds of
> features (for example its currently talked about using the libgcc.so
> in a DT_AUXILIARY entry).
> 
> >   > - add more legacy interface which are needed but are not supported
> >   >   anymore by gcc or which do some data rewriting before calling the
> >   >   actual libgcc functions
> > Agreed, if you're going to do this then I'd like to see it happen completely
> > outside gcc.  I'm not sure how wise it is, but if we provide both libgcc.a
> > and libgcc.so, you'll still have this capability.

Hey!  This is the whole point of having libgcc.so.  If it's going to
be done outside gcc, then the whole libgcc.so needs to be done outside gcc.

> So you basically already agree that the work has to be done outside gcc.

> >   > The alternative is to find somebody (or a group) for each of the
> >   > arch/OS combinations which care about compatibility at this level and
> >   > have them maintain the data inside gcc and to significantly extend the
> >   > build infrastructure to handle the soname and versioning requirements.
> > Yup.  That's how things have always been done in gcc-land.  
> 
> But I don't believe this will work.  It didn't work so far.

I don't think this will work either.  It's not something that can be
done by a group inside gcc, every maintainer who can change the
affected files must understand the issues.  (At present, that includes
all the target-specific .h files.)

-- 
- Geoffrey Keating <geoffk@cygnus.com>