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

[David Holmes]

On 4/01/2024 1:36 pm, Glavo wrote:
> Hey David,
> 
>     AFAICS java.library.path (and sun.boot.library.path) are input
>     properties that can be set by the user. There are no "default" values
>     for these properties as such.
> 
> 
> Although they can be set by the user, they have default values.
> For Linux, the default value is set here:
> 
> https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555>
> 
> The default value on Linux is the LD_LIBRARY_PATH environment variable 
> and the paths I mentioned earlier.
> 
>     The library loading will ultimately rely
>     on the behaviour of dlopen, if no additional paths have been set, so it
>     seems to me what you really want is for dlopen to act "the same way"
>     that ld does. Note that dlopen will already check the contents of
>     /etc/ld.so.cache
> 
> 
> System.loadLibrary looks for the library in sun.boot.library.path and 
> java.library.path and passes the full path to the library to dlopen:
> 
>     https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254 <https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254>
> 
> Therefore, the behavior of finding native libraries has nothing to do 
> with the behavior of dlopen, only sun.boot.library.path and 
> java.library.path.

I stand corrected - apologies. I expected a raw name to simply get 
passed through. I thought both LD_LIBRARY_PATH and java.library.path 
could be used to expand the set of directories where the platform code 
looks for libs, not constrain things to only those paths (plus the 
defaults). I expect there are security reasons why the JDK tries to find 
the file itself in these specific paths, rather than letting the 
platform code search for it.

>     This does not seem practical. On my system ld.so.conf just contains
> 
>     include ld.so.conf.d/*.conf
> 
>     so now we (hotspot) have to read the top-level file, parse it, interpret
>     it and then recursively read, parse and interpret more files.
> 
> 
> Yes, this is exactly the behavior I want.

Well that is not something I would want to see implemented in hotspot.

Cheers,
David
-----

> Glavo
> 
> On Tue, Jan 2, 2024 at 10:08 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Glavo,
> 
>     On 24/12/2023 4:18 am, Glavo wrote:
>      > Hi,
>      >
>      > There are already many Linux distributions that are following the
>      > multiarch-spec[1] and adding the following paths to the default
>     library
>      > path list:
>      >
>      >   * /usr/local/lib/<triplet>
>      >   * /lib/<triplet>
>      >   * /usr/lib/<triplet>
>      >
>      > But OpenJDK doesn't add these paths to the java.library.path by
>     default,
>      > so System.loadLibrary(String) has annoying behavior differences
>     with ld.
> 
>     AFAICS java.library.path (and sun.boot.library.path) are input
>     properties that can be set by the user. There are no "default" values
>     for these properties as such. The library loading will ultimately rely
>     on the behaviour of dlopen, if no additional paths have been set, so it
>     seems to me what you really want is for dlopen to act "the same way"
>     that ld does. Note that dlopen will already check the contents of
>     /etc/ld.so.cache
> 
>      > Many libraries already installed on the system cannot be found by
>      > System.loadLibrary(String).
>      >
>      > I wish OpenJDK would parse the /etc/ld.so.conf to get the full
>     library
>      > path list so it would be consistent with the behavior of ld.
>      > Can anyone consider this suggestion?
> 
>     This does not seem practical. On my system ld.so.conf just contains
> 
>     include ld.so.conf.d/*.conf
> 
>     so now we (hotspot) have to read the top-level file, parse it,
>     interpret
>     it and then recursively read, parse and interpret more files.
> 
>     Cheers,
>     David
>     ----
> 
> 
>      > Glavo
>      >
>      > [1]: https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>
>      > <https://wiki.ubuntu.com/MultiarchSpec
>     <https://wiki.ubuntu.com/MultiarchSpec>>
>