RTLD_GLOBAL vs RTLD_LOCAL
from the dlopen man pages ( Linux ):
The symbols defined by this library will be made available for symbol resolution of subsequently loaded libraries.
This is the converse of RTLD_GLOBAL , and the default if neither flag is specified. Symbols defined in this library are not made available to resolve references in subsequently loaded libraries.
If filename is a NULL pointer, then the returned handle is for the main program. When given to dlsym (), this handle causes a search for a symbol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen () with the flag RTLD_GLOBAL .
External references in the library are resolved using the libraries in that library’s dependency list and any other libraries previously opened with the RTLD_GLOBAL flag. If the executable was linked with the flag “-rdynamic” (or, synonymously, “–export-dynamic”), then the global symbols in the executable will also be used to resolve references in a dynamically loaded library.
Julia defaults to dlopen(RTLD_LOCAL) on linux. So anything Julia dlopens: the symbols defined by that library will not be made available for symbol resolution of subsequently loaded libraries. This seems ok.
If libjulia.so was dlopened with RTLD_LOCAL then it’s symbols won’t be available to anything it dlopens. Not clear what flags the dynamic linker will open libjulia’s dependencies with. This seems to create a problem.
For example, if you build a custom system image, it won’t be able to call any functions in libjulia, which seems a bit crippling. My example here is assuming sys.so ( or whatever your system image is called ) is dlopen by libjulia, which was the case in 0.6, but may not be true now, I haven’t stepped/grepped though the code to confirm it’s still doing so.