Re: The DT_AUXILIARY patch

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

On Sat, Jul 15, 2000 at 03:20:23PM +0200, Mark Kettenis wrote:
>    Date: Fri, 14 Jul 2000 18:31:28 -0700
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    On Fri, Jul 14, 2000 at 06:27:34PM -0700, H . J . Lu wrote:
>    > Here is the DT_AUXILIARY patch for the shared libgcc. After some
>    > experiments, I believe we shouldn't even need libgcc.so under Linux.
>    > We just set the DT_AUXILIARY to libgcc.so$(libgcc.so-version). We will
>    > only have /lib/libgcc.so$(libgcc.so-version) which is symlinked to
>    > /lib/libgcc-3.0.so. /lib/libgcc.so$(libgcc.so-version) is hidden from
>    > user. Everything is still linked with libgcc.a.
>    > 
> 
>    BTW, we just need to make sure everything exported from the shared
>    libgcc is also exported from libc.so. I think we will be safe then.
> 
> That would be an incredibly stupid thing to do, since it means that
> you'd have to recompile glibc whenever things are added to libgcc.so.
> 

That is true. The isse is we need to find a way to make the references
to those exported symbols in libgcc.so dynamic. That is what libgcc.so
is used for. How about we teach ld to check DT_AUXILIARY? It will
be treated as DT_NEEDED for that purpose. ld won't wont propagate
DT_AUXILIARY to anything else.

> You'll probably have to install a libgcc.so linker script in the same
> directory as libgcc.a, and preferably create a libgcc_nonshared.a

That is no need for libgcc_nonshared.a, we can just use libgcc.a.

> there too.  Of course this can be postponed until you actually add
> new stuff to libgcc.so.

I don't like libgcc.so since it will introduce explicit dependency
on libgcc.so and with DT_AUXILIARY, the only thing we need is to
make the references to to those exported symbols in libgcc.so dynamic.
Without libgcc.so, the resulting binaries will run ok with the slightly
older libc.so which has no DT_AUXILIARY as long as the ABI of libgcc
is not changed too much.


H.J.