Re: Duplicate data objects in shared libraries

[David Beazley <beazley at cs dot uchicago dot edu>]

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

-- Dave