The default java.library.path on Linux does not include the library paths in the mulitarch-spec

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Jan 5 15:01:58 UTC 2024


Hi Glavo,
parsing ld.conf is something that some frameworks do (e.g. JNR). Last 
time I checked there was some concerns in having hotspot bootstrap code 
depending on the results of an external tool, whose output could change 
over time. Currently, IIRC the list of path is just a compiler constant 
(a macro), which is altered on a per distro basis.

As for Panama, note that the SymbolLookup API allows a better way to 
load system libraries, with its SymbolLookup::libraryLookup factory:

https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)

This is essentially a "raw" wrapper around dlopen/dlsym. So, each name 
you can see in `ldconfig -p`, you will be able to load it with this method.

As Sebastian mentioned, the process of loading system libraries is higly 
OS-dependent. On Linux, you have to wrestle with version numbers (e.g. 
GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system 
libraries are not even present in the file-system [1]. So, I'm afraid 
that loading a system library is a more involved process than just 
setting up a bunch of paths correctly - which might work in the 80% 
cases, but still fail in other cases. Overall, the general feeling is 
that System::loadLibrary tries to expose library loading in a 
minimum-common-denominator kind of approach (which is common to a lot of 
JDK APIs), and trying to make that mechanism more flexible might be a 
lost cause, or not have a great return on investment. The raw 
SymbolLookup wrapper shown above bypasses all these issues, and uses 
whatever library lookup mechanism the underlying OS prefers. Advanced 
users should definitively prefer the latter when working with system 
libraries (esp. when doing so using the FFM's Linker).

Maurizio

[1] - 
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes

On 04/01/2024 14:24, Glavo wrote:
> This is the only way I can think of to get the JDK to behave 
> consistently with ld.
> Maybe we should wait and see other developers who are more familiar 
> with this part.
>
> I'm now sending this email to panama-dev as well.
> I think this proposal is of great significance to Panama, as it will 
> make it easier for developers to develop wrappers for platform libraries.


More information about the panama-dev mailing list