library loading - continued
notzed at gmail.com
Wed May 12 00:07:35 UTC 2021
On 11/5/21 7:37 pm, Maurizio Cimadamore wrote:
> Which gives away the real location of the library:
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 . 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
*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
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.
More information about the panama-dev