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

[Ulrich Drepper <drepper at redhat dot com>]

Jeffrey A Law <law@cygnus.com> writes:

> This seems totally backwards to me.  GCC knows about things like it's
> install directory,

Right here you are wrong.  The libgcc.so must never ever installed in
a gcc-specific directory.  Just think about what this would mean.

> what version # to use for libgcc,

This implies you are willing to track the version numbers for all the
different target.  Again, my argument is that you are *not* able to do
this accurately since you cannot effort spending that much time on it.

> 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.

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.

> 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.

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

> 
>   > - create and install the actual libgcc.so with the appropriate soname
> What about moving this into a different package makes it easier than having
> it in gcc?  I'm thinking about install paths, multilibs and the like -- GCC
> knows about that stuff, and I'm not keen on expanding the number of packages
> that need to know about such braindamage.

Again, multilibs are uninteresting.  The install directory will be
/lib on Linux and similar directories for other systems.

>   > 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.

>   > Everybody who just dismissed HJ's proposal should stop and think about
>   > this for a moment.  Will you be willing to do what I described inside
>   > gcc?
> Yes.

You have to show me it works before I believe it.

> Yup.  You can hide all kinds of interesting things in .a files.  But is
> that really a good idea?  Presumably you're looking at this as a way to
> pass information from gcc to some external package which builds the
> shared library.

Right.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------