For the c++std-ext recipients, just added: previous messages in this thread, which concerns the semantics of shared libraries w.r.t. exception-handling and other C++ features which require "vague linkage", can be found here: http://gcc.gnu.org/ml/gcc/2002-05/msg00866.html http://gcc.gnu.org/ml/gcc/2002-05/msg00869.html http://gcc.gnu.org/ml/gcc/2002-05/msg00873.html ----- Original Message ----- From: "Jason Merrill" <jason@redhat.com> > > 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? The test as written doesn't really tell us the answer since it uses EH and any implementation can make it a non-issue by comparing type_info::name() strings instead of addresses. The test could easily be modified the so it looks at the address of a class template's static data member, of course. > > 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? I guess you /know/ what I think: I just want it to work ;-) I'd also like to point out what I think is a fundamental difference in the Windows and Linux models for shared libraries: in the Windows model, sharing has a "direction" but in the Linux model the direction is determined by who got there first. So, for example, in the Windows model when lib.dll and lib2.dll are loaded there are certain symbols which come in from their dependency, X.dll, because they're explicitly imported. It's the fact that the libraries explicitly "pull" symbols from their dependencies that makes the model work. In the Linux model, it appears that lib1.so and lib2.so essentially load everything they've got and "push" their symbols onto X.so. In the case we're looking at, the dependency may already be loaded so the push might leave us with two copies of some symbols in the lib<N>.so/X.so relationship. -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