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

["H . J . Lu" <hjl at lucon dot org>]

On Tue, Jul 11, 2000 at 12:51:24AM -0700, Ulrich Drepper wrote:
> > If his proposal was to provide a -fPIC libgcc object file collection
> > which is transformed into a shared library during glibc installation -
> > that won't work. I don't think users will want to rebuild glibc as
> > part of gcc installation.
> 
> I don't think this works either.  This is my I'm currently favouring a
> standaline package.  But there might be situation where a new libc
> might require a new version of the libgcc.so and therefore there must
> be some kind of coupling between this new package and glibc.  Perhaps
> something like an add-on (in the glibc-sense) which can also be used
> standalone).
 
A standalone package, which can also be used as a glibc add-on, seems
a reasonable solution. That will be target specific.

I have to remind everyone that we have to have a stable, reasonable
libgcc runtime ABI before we can build libgcc.so. We have to support
any ABI functions forever. It doesn't mean gcc has to support the
old ABI functions directly. But the standalone package has to. It
has to be able to find a way to support old ABI functions somehow.
We can do many things under Linux. But we still need some support
from gcc.

I am thinking libgcc.so may look like

GROUP (/lib/libgcc.so /usr/lib/libgcc_nonshared.a)

where /lib/libgcc.so only contains libgcc funtions which can only have
one copy cross the executable and all DSOs. We should identify tham
first.


H.J.