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

Glavo zjx001202 at gmail.com
Thu Jan 4 03:36:28 UTC 2024


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

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

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.

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.

Glavo

On Tue, Jan 2, 2024 at 10:08 AM David Holmes <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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240104/9870ac5f/attachment-0001.htm>


More information about the core-libs-dev mailing list