This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimal GCC/Linux shared lib + EH bug example

>>>>> "David" == David Abrahams <> 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
> is sharing globally with but not with, 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:
> [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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]