Re: Duplicate data objects in shared libraries

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

On Mon, May 20, 2002 at 06:12:35AM +0100, Jason Merrill wrote:
> Let me try to summarize the discussion:
> 
> The semantics of existing SVR4 dynamic linkers are such that:
>    IF two shared objects A.so and B.so link against the same shared 
>      library C.so, AND
>    both override the same symbol S, AND
>    A.so and B.so are loaded in that order with RTLD_LOCAL, THEN
>    all references to S from A.so and C.so will resolve to the copy from
>      A.so, but references from B.so will resolve to the copy from B.so.
> 
> This is true because:
>    There is only one copy of C.so loaded, and its relocs are only resolved
>      once, AND
>    the definitions from A.so and C.so are not visible when loading B.so.
> 
> This breaks RTTI matching, which relies on all references within a
> program resolving to the same copy.  Since references from B.so and C.so
> differ, this premise is violated.
> 
> It is generally agreed that this is unfortunate.  Yes?
> 
> Various solutions present themselves.  Most basically, they break down to:
> 
> 1) Change the dynamic linker so that B.so and C.so agree, AND/OR
> 2) Change the runtime so that it doesn't matter if they don't agree.
> 
> 
> Possible implementations of #1:
> 3) If a library needed by an RTLD_LOCAL object is already loaded, ignore it
>    and map a new copy.  As an optimization, only do this if it refers to
>    symbols defined by the RTLD_LOCAL object.
> 4) If a library needed by an RTLD_LOCAL object is already loaded, force the
>    library to RTLD_GLOBAL status so that references from B.so will use the
>    already-resolved definition.
> 
> I think #3 is philosophically cleaner.
> 
> Have I missed any arguments?
> 

I saw RTLD_GROUP in Solaris 8 dlopen man page and it says the scope of
RTLD_LOCAL is for the dlopen group. I was wondering what the dlopen
group meant and if it applied to A.so, B.so and C.so here.


H.J.