[Python-Dev] Re: Minimal GCC/Linux shared lib + EH bug example
Sun, 12 May 2002 14:42:06 +0100
>>>>> "David" == David Abrahams <email@example.com> writes:
> 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.
And on Windows, we don't rely on address equivalence.
> 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.
I noticed that the readme says that the test passes on Solaris. Does it
provide these semantics? How about SCO? Anyone?
> 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].
Yes, 3.1 still relies on pointer comparison.
I find this testcase somewhat persuasive, as the offending dlopen call is
not in the C++ code. What do others think?