>>>>> "David" == David Abrahams <david.abrahams@rcn.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? Jason
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4