library loading - continued

[Maurizio Cimadamore]

On 12/05/2021 01:07, Michael Zucchi wrote:
> Well dlopen finds it ok as it's on the system path, assuming you know 
> the actual libc name to use (which is in the elf program headers or 
> known at compile time for the java executable).  The requirement of an 
> absolute path for System.load() as well as support for 'system 
> libraries' is perhaps conflicting here because the "system libraries" 
> can be changed on a per-process basis via elf headers and 
> environmental variables.
>
> *ldconfig -p wouldn't even be correct regardless* since that just 
> prints the ld.so.cache contents.  It wont take into account 
> LD_LIBRARY_PATH or -rpath nor the fact that a given binary can use an 
> alternative interpreter (ld-linux.so.x) and any libc which that given 
> ld-linux is compatible with, discovered via the load path. The only 
> hard-coded absolute path is the interpreter name, and that is what 
> determines the search paths to use.
Yes. Many tools out there do just that - but I'm aware that even the 
ldconfig solution isn't bullet proof.
>
> Presumably what you need is the libc actually bound to the current 
> java process?  For the latter "pldd" walks the auxiliary table for the 
> runtime ELF program headers which includes the full paths to the 
> libraries loaded.
We had something like this on Windows, before this change. While walking 
ELF headers is always an option, it also seems a brittle one, as it 
still involves some parsing logic which might break.
>
> Seems overly complicated to duplicate when dlopen("<name of libX in 
> program header>" or actually "<name of libX java was compiled 
> against>" - as per the example in the dlopen man page) should already 
> do this.  And as already seen in this thread 'glibc' is actually a 
> somewhat large collection of libraries so you're already bound to a 
> platform /and/ (g)libc specific bunch of "system" names (i.e. 
> /usr/include/gnu/lib-names-64.h) 

Using dlopen + lib-names is, IMHO, the best approach, in the sense that 
the macros in there would give away the full name of the libraries used 
when building the JVM, and then dlopen would do the rest, in terms of 
finding where these libraries actually are.

But note that what we ended up doing is not very different: we just 
create a shim library which depends on libc/libm/libdl and dlopen that. 
I don't think there will be any material difference for the user? The 
advantage of the solution we used is that it is pretty straightforward, 
and works on MacOS too. But I mean, these are all implementation details 
- we could, in the future, switch to some other implementation strategy 
which allows us to create a "system" lookup... as long as we agree on 
the fact that some kind of system lookup is desirable.

Maurizio