Re: Duplicate data objects in shared libraries

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

On Mon, May 20, 2002 at 02:40:31PM -0500, David Beazley wrote:
> Jason Merrill writes:
>  > >>>>> "David" == David Abrahams <david.abrahams@rcn.com> writes:
>  > 
>  > > #3 would be much worse for me than the status quo is. The scenario is that
>  > > my clients are writing extension modules loaded with RTLD_LOCAL. In order
>  > > to function properly, these modules must share a copy of a common library:
>  > > each module "publishes" some data through calls to the common library and
>  > > also "subscribes" to all the data in the library. It sounds like ensuring
>  > > that the library is actually shared in #3 would be next-to-impossible.
>  > 
>  > #3 comes from a conception of RTLD_LOCAL as a partitioning of the system
>  > into independent parts ("programs", in earlier messages); if you want to
>  > exchange information between two such objects via a common library, that
>  > model is inadequate.
> 
> I've been quietly sitting on the sidelines for most of this
> discussion, but I'd like to reiterate David's comment above.  #3 would
> definitely break a lot of big applications that rely on scripting
> language extension module interfaces.  It is fairly common for an
> application to be broken up into independent dynamic modules---all of
> which link against a common runtime library.  This runtime library may
> manage things related to networking/parallel computing (MPI, etc.) or
> other shared state.  Creating independent copies of the same library
> would just be a huge disaster.
> 
>  > Perhaps the right approach is
>  > 
>  > 5) Do not allow an object loaded with RTLD_LOCAL to override symbols from a
>  >    dependency.
>  > 
>  > This rule is easily stated; it would cause both A.so and B.so to refer to
>  > the definition in C.so, regardless of the order of loading.  I like it.
> 
> Hmmm. Interesting. As far as I know, this wouldn't break anything in
> the typical use of dynamic loading. At least in Python, extension
> modules aren't meant to serve as libraries nor do you normally try to
> override library symbols (at least not on purpose).  However, I don't
> recall any sort of ELF/dynamic linking option that would achieve this
> kind of effect (it seems like it is the opposite of how libraries are
> normally linked).  

Just load C.so first. It should work. I know it doesn't work on Linux.
I am working on a testcase in C to fix it.


H.J.