The DT_AUXILIARY patch

[Mark Kettenis]

   Date: Sat, 15 Jul 2000 10:03:41 -0700
   From: "H . J . Lu" <hjl@lucon.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>
   > 
   >    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.

Argh!  No!  The current behaviour of ld to walk the DT_NEEDED list
when resolving symbols from shared libraries has its problems and is
incompatible with at least the Solaris linker.  See
< http://sources.redhat.com/ml/binutils/1999-11/msg00037.html > for a
discussion.  Adding this for DT_AUXILIARY makes even less sense.  If
the library in DT_AXUILIARY is absent everything should still work.
Our proposed use of DT_AUXILIARY is more or less abusing the concept.
It seems to work, but isn't really appropriate.  Let's not bias our
tools too much to this particular use.

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

Nasty, isn't it?  That's why I said you could postpone explicitly
linking against libgcc.so until the ABI of libgcc actualy changes.
However, as soon as it does, you'll have no other choice.

In principle, there is no need for the shared libgcc.so at all as long
as you don't use exception handling.  So perhaps it is possible to
tweak things (using linker tricks and the GCC specs file) to avoid the
explicit dependency on libgcc.so for plain C programs.

Mark