The ABI status of ELF hash tables

It is not the same. RTLD_LOCAL is not usable in open-ended "I load plugins via dlopen" mechanisms. The problem is when you have:

pluginA.so -> liblang.so
pluginB.so -> liblang.so

Loading pluginA with RTLD_LOCAL makes liblang.so enter the same state. When pluginB is loaded, it fails because it is not "allowed" to access liblang.so because it is "local" to pluginA. It's probably more useful when you know plugins are standalone or you're doing some restricted delay-load mechanism.

What windows does is a lot closer to dlmopen than it is to RTLD_LOCAL. In windows if you load (or link against) two dlls that both link against the same dll themselves, then they can very well use different versions of that dll.

You can actually have stuff like multiple different C runtimes in the same process (although it's super likely to result in sadness and chaos as soon as one touches the other). Still, if you are very careful it is possible. They do need to be named differently though.

Not to mention if you load C++ libraries with RTLD_LOCAL they usually can't be unloaded anyway, _AND_ some (but not all) of their symbols will actually be used to resolve references in future libraries. RTLD_LOCAL can also be promoted to RTLD_GLOBAL if the library is a dependency of an RTLD_GLOBAL library.

dlmopen provides something much more similar to windows DLLs, but you can only have 16 namespaces and according to the manual (typos from there):
> As at glibc 2.24, specifying the RTLD_GLOBAL flag when calling
dlmopen() generates an error. Furthermore, specifying
RTLD_GLOBAL when calling dlopen() results in a program crash
(SIGSEGV) if the call is made from any object loaded in a
namespace other than the initial namespace.

So it seems like it's a little useless. Someone should fix this stuff, and perhaps allow some kind of namespacing for stuff used via the linker, without dlsym. I guess if you really want that you can just use wine's loader.