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

[Jeffrey A Law <law at cygnus dot com>]

  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.

  > 
  > > 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
capability across a number of systems to resolve a number of nasty problems.

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.


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

  > Again, multilibs are uninteresting.  The install directory will be
  > /lib on Linux and similar directories for other systems.
Multilibs are very interesting, and I don't think it's a given that the
install directory will be /lib.  I believe that is still subject to debate.


jeff