This is the mail archive of the
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
- From: Jason Merrill <jason at redhat dot com>
- To: "David Abrahams" <david dot abrahams at rcn dot com>
- Cc: <python-dev at python dot org>,"Ralf W. Grosse-Kunstleve" <rwgk at cci dot lbl dot gov>, <gcc at gcc dot gnu dot org>,"Martin v. Loewis" <martin at v dot loewis dot de>
- Date: Sun, 12 May 2002 14:42:06 +0100
- Subject: Re: Minimal GCC/Linux shared lib + EH bug example
- References: <firstname.lastname@example.org><email@example.com><firstname.lastname@example.org>
>>>>> "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?