From what I can tell, in LLVM the clients of this are solely clang and lldb.
Nothing should break for them as they explicitly search single libraries for symbols.
D33529 attempts to mitigate any problems that might occur for external usage by giving greater control of how symbols are searched.
But moving to RTLD_LOCAL by default though, may cause breakage for clients of the JIT as a normal pattern would be:
1. DynamicLibrary::getPermanentLibrary(nullptr); // synonym for Process = dlopen(nullptr, RTLD_LAZY | RTLD_GLOBAL); 2. // Other code... 3. DynamicLibrary::getAddressOfSymbol("SomeSymbol"); // synonym for dlsym(Process, "SomeSymbol");
A. If any other libraries were loaded RTLD_LOCAL by default in step 2, step 3 would no longer find the symbols. (though again, D33529 should make it easy to update their implementation).
B. On Windows this behaviour would differ as there is no concept of RTLD_LOCAL and that would have to be tracked by hand if parity was wanted.
I kind of think the cost against A is worth it as the injection of symbols globally is generally bad, but the disparity of behaviour from B gives me pause.
The easiest solution for B would rely on Module Handles being the same across calls which I don't think is documented but perhaps worth the risk?
In other words D33529 broke the cases where we dlopen with RTLD_LOCAL (like cling and ROOT) and this should fix it.
@marsupial I've tested these patches and it looks like they do not fix the regression. I'd be interested in solving this issue for the upcoming release. If nothing works I will have to revert D33529 :(
This has nothing to do with fixing your issue and is solely to allow clients to load via RTLD_LOCAL.
I don't see how D33529 could have broken anything as it is not committed yet. D33529 attempts to address what I understand is your issue.
If it's not working perhaps you could explain or provide a bit more info what doesn't work...(on that thread not here).
Perhaps @pcanal can help with that?