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

["H . J . Lu" <hjl at valinux dot com>]

On Tue, Jul 11, 2000 at 10:34:05AM -0600, Jeffrey A Law wrote:
>   In message <m3bt04k58c.fsf@otr.mynet.cygnus.com>you write:
>   > 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.
> Yes, I'd forgotton about that.  It's one of the issues that needs to
> be addressed.  However, I'm not going to say "must never", just that it's
> an issues that must be resolved in one way or another.
> 

I don't think Linux has much choice. It probably has to be installed
along side with libc.so.

>   > 
>   > > 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.
> But we need to -- we're not just building a linux compiler.  We need this

Look it this way. Since gcc is not a linux specific compiler and
the libgcc/libc issuse is limited to very few targets, why should
gcc spend HUGE amount of time up front and for continuing support?

> capability across a number of systems to resolve a number of nasty problems.

Can you name systems which have the same issue? Maybe we should talk
to them to see what they want to do.

> Punting it to an external package is just that -- punting.
> 
> 
>   > > 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.
> Some native systems have multilibs.  alphas for example, maybe sparcs.
> And in the embedded linux world we will likely have systems that need
> multilibs.  We can't simply ignore those issues.

Linux (glibc) has its own multilibs support, for SHARED LIBRARIES, not
just for static libraries. When Ulrich said "multilibs are
uninteresting", I take it meant comparing with the solution for
multilibs SHARED LIBRARIES in glibc, the one in gcc looks dumb if not
stupid.

>   > So you basically already agree that the work has to be done outside gcc.
> No, I said that it is technically possible to do what you want outside
> of GCC given what we provide in libgcc.a.  I did _NOT_ say that the
> "work has to be done outside gcc".  Far from it.
> 

Please keep in mind we are talking DSO here. gcc never has any good
track record on the support for binary compatibility in DSOs. I put in
something called "library interface." But it is not enough for backward
binary compatibility. The glibc's track record is not perfect, but it
is quite good and we have leaned a lot from our experiences.


-- 
H.J. Lu (hjl@gnu.org)