library loading - continued

[Michael Zucchi]

Morning,

On 11/5/21 7:37 pm, Maurizio Cimadamore wrote:
>
>
> Which gives away the real location of the library:
>
> /lib/x86_64-linux-gnu/libc.so.6
>

As an example non-multilib systems just put it in /lib64, probably. But 
where it's found is really up to ld-linux(8) (at least with glibc).

> We've been looking around for a "standard" way to discover the 
> location of these system libraries and came up pretty empty handed. 
> The best way seems to be to run:
>
> ldconfig -p
>
> And then filter the output in some way. Is the output format stable? 
> Of course not - see [1]. So, while there's nothing wrong with 
> System.loadLibrary in terms of "library loading" ability, on linux 
> there is simply no great way to tell where libc is.
>

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.

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.

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)

  Z