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.hol...@oracle.com
<mailto:david.hol...@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>>
