This is the mail archive of the
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
On Mon, May 20, 2002 at 02:40:31PM -0500, David Beazley wrote:
> Jason Merrill writes:
> > >>>>> "David" == David Abrahams <firstname.lastname@example.org> 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.