----- 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
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