Re: The DT_AUXILIARY patch

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

On Sat, Jul 15, 2000 at 07:48:17PM +0200, Mark Kettenis wrote:
>    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

I didn't find the original message. Is the original problem solved?
I ran into a similar problem with OpenGL. One OpenGL implmenentation
is multi-threaded. But it has to work with single thread applications.
That means the OpenGL implmenentation has to make sure libpthread.so
is always available even if it is used with a single thread application.
I had to fix a bug in glibc to make things to work for them. I can ask
them to see how they solved the problem.

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

As I said, ld will check DT_AUXILIARY for setting a symbol dynamic.
That means you don't need to use "gcc -rdynamic". I will make sure it
won't have any other bad side effects.

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

That is what I want to avoid.

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

That won't work since there is no way to tell if any C++ codes exist
or not. I can even implement glibc in C++ as long as I support the
glibc ABI.


H.J.