Re: Duplicate data objects in shared libraries

["David Abrahams" <david dot abrahams at rcn dot com>]

From: "Mark Mitchell" <mark@codesourcery.com>

> > I think that being able to write plugins in C++ is important, and a
>
> I guess I just don't think that using RTLD_LOCAL is the only reasonable
> way to do it.

If you are writing an application which loads plugins which may be written
in "C", it is pretty-much the only reasonable way to do it. Martin details
the reasons quite nicely here:

http://aspn.activestate.com/ASPN/Mail/Message/1190320

...and although namespaces mitigate things a bit, I think the arguments
still apply to C++.

> But, if there's a good solution here, we should definitely do it.

I just spent some more time discussing Jason's #5 solution with him, and
trying to find problems with it. We weren't able to find any; it does seem
to provide the desired semantics in all cases we could imagine with a
minimum of subtlety and complication.

One thing we didn't discuss in detail was what should happen in case two of
a library's dependencies are already loaded, each with its own definition
for some shared symbol S. There are two possiblities I can imagine:

1. Pick one
2. Error

Unless we get a new symbol label which means "must be shared", I'm strongly
in favor of 1. In many cases there's no detectable difference when symbols
aren't actually shared (for example, inline functions with no static data
and which nobody takes the address of), and I don't want to make otherwise
legitimate uses fail. Even if we had a "must be shared" label, describing
how to implement suitably selective error reporting is not simple.

-Dave