Jason, I had to write all the following exposition to understand your reply, but then it dawned on me what you meant ;-) I wrote, describing existing Linux/GCC semantics: > >>> 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. <snip> And then, describing my preferred semantics: > >>> 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. Jason replied: > >> I noticed that the readme says that the test passes on Solaris. Does it > >> provide these semantics? How about SCO? Anyone? Assuming by "these semantics", Jason meant my preferred semantics: > > 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. > > I meant using gcc 3.0.4 on Solaris. Ah yes, GCC 3.0.4 would tell us something, since it is using address comparison. If it worked on Solaris, that would be just as good as using a different test with that looked at addresses of template static data members. Good question. -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