[Python-Dev] Re: Minimal GCC/Linux shared lib + EH bug example

[David Abrahams]

----- Original Message -----
From: "Jason Merrill" <jason@redhat.com>

> IMO, it is unreasonable to expect C++ to work with RTLD_LOCAL unless the
> object so loaded is indeed self-contained (which precludes linking
against
> a common shared library, as in this case).  Too many aspects of the
> language depend on being able to merge duplicates coming from different
> sources.

I think there's an implicit assumption in your statement which should be
brought into the open: that there's an agreed-upon idea of what it means
for C++ to "work" with shared libraries. As you know, the language standard
doesn't define how share libs are supposed to work, and people have
different mental models. For example, on Windows, imports and exports are
explicitly declared. Nobody expects to share static variables in inline
functions across DLLs unless the function is explicitly exported. However,
exception-handling and RTTI /are/ expected to work.

> In this case, the problem comes from std::type_info; the runtime
> library expects to be able to compare type_info nodes by pointer
> equivalence.  Templates and static variables in inline functions would
also
> have trouble.

As I understand (guess) it, what happens is this:

1. lib1.so is loaded with RTLD_LOCAL. All of its symbols go into a new
"symbol space"
2. the loader notices the dependency on X.so, and loads any /new/ symbols
from the shared lib X.so into the same space, eliminating duplicates.
3. Now that all dependent libs are loaded, any unresolved symbols in
lib1.so and X.so are resolved now; if any fail to resolve or there are
duplicates, runtime error.
-----
4. lib2.so is loaded with RTLD_LOCAL. Because it's RTLD_LOCAL, the loader
again creates a new "symbol space"; no duplicates are shared with X.so.
5. The loader notices the dependency on X.so, but X.so is already loaded
6. Any unresolved symbols in lib2.so (and X.so, though there are none) are
resolved now
-----

What I'd prefer to happen is that in step 4, the loader would use the
existing definition for any loaded symbol which is defined in or used by
lib2's immediate dependencies. That would nicely model the concept that
lib2.so is sharing globally with X.so but not with lib1.so, and it seems
like the "right" solution.

However, for my application I'd be content if EH was just comparing the
type_info::name() strings, as Martin von Loewis stated was the case in
2.95.x and again in 3.1:
http://aspn.activestate.com/ASPN/Mail/Message/1191899 [This statement
appears to be contradicted empirically, though: Ralf reports similar
problems with GCC 3.1 - GNATS id 6629]. This would bring GCC sufficiently
close to the model of Windows compilers (and of compilers on the other *NIX
OSes he's tested on) to allow practical cross-platform authoring of plugins
in C++.

-Dave