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

[CC]

Hi,

I see your point. Doing this from the JDK side would be a bit too specific, and specifying a custom path would be the way to go in this case. However, there’s another solution that would probably be more useful: Allowing the library path to be changed at runtime.

I have recently had my own experience with the library path, and wanted to change it to include some other paths where my actual system libraries were. While this would be a job for a custom start script, the app was built to a single fat jar, and a start script would require me to remake the packaging process. When I tried to change the library path, I realised that it is actually cached after the first request to it, which means it is effectively not changeable after the JVM starts.

Allowing the library path to be changed would allow for the logic described previously to work, even if the JVM itself does not implement it itself, among with all other mechanisms for the library path.

Cheers,
Constantin
Am 2. Jan. 2024, 03:09 +0100 schrieb David Holmes <david.holmes at oracle.com>:
> 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/jdk-dev/attachments/20240102/bea86646/attachment.htm>