<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I expect there are security reasons why the JDK tries to find<br>the file itself in these specific paths, rather than letting the<br>platform code search for it.<span class="gmail-im"><br></span></blockquote><div><br></div><div>I think this should have nothing to do with security. If there is a vulnerability in the platform code, there is nothing the JDK can do to avoid it.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well that is not something I would want to see implemented in hotspot.<br></blockquote><div><br></div><div>This is the only way I can think of to get the JDK to behave consistently with ld. </div><div>Maybe we should wait and see other developers who are more familiar with this part.<br></div><div><br></div><div>I'm now sending this email to panama-dev as well.<br></div><div>I think this proposal is of great significance to Panama, as it will make it easier for developers to develop wrappers for platform libraries.<br></div><div><br></div><div>Glavo</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 4, 2024 at 3:12 PM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/01/2024 1:36 pm, Glavo wrote:<br>
> Hey David,<br>
> <br>
>     AFAICS java.library.path (and sun.boot.library.path) are input<br>
>     properties that can be set by the user. There are no "default" values<br>
>     for these properties as such.<br>
> <br>
> <br>
> Although they can be set by the user, they have default values.<br>
> For Linux, the default value is set here:<br>
> <br>
> <a href="https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555</a> <<a href="https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/hotspot/os/linux/os_linux.cpp#L532-L555</a>><br>
> <br>
> The default value on Linux is the LD_LIBRARY_PATH environment variable <br>
> and the paths I mentioned earlier.<br>
> <br>
>     The library loading will ultimately rely<br>
>     on the behaviour of dlopen, if no additional paths have been set, so it<br>
>     seems to me what you really want is for dlopen to act "the same way"<br>
>     that ld does. Note that dlopen will already check the contents of<br>
>     /etc/ld.so.cache<br>
> <br>
> <br>
> System.loadLibrary looks for the library in sun.boot.library.path and <br>
> java.library.path and passes the full path to the library to dlopen:<br>
> <br>
>     <a href="https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254</a> <<a href="https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/blob/1cf9335b24639938aa64250d6862d9636f8605f8/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L246-L254</a>><br>
> <br>
> Therefore, the behavior of finding native libraries has nothing to do <br>
> with the behavior of dlopen, only sun.boot.library.path and <br>
> java.library.path.<br>
<br>
I stand corrected - apologies. I expected a raw name to simply get <br>
passed through. I thought both LD_LIBRARY_PATH and java.library.path <br>
could be used to expand the set of directories where the platform code <br>
looks for libs, not constrain things to only those paths (plus the <br>
defaults). I expect there are security reasons why the JDK tries to find <br>
the file itself in these specific paths, rather than letting the <br>
platform code search for it.<br>
<br>
>     This does not seem practical. On my system ld.so.conf just contains<br>
> <br>
>     include ld.so.conf.d/*.conf<br>
> <br>
>     so now we (hotspot) have to read the top-level file, parse it, interpret<br>
>     it and then recursively read, parse and interpret more files.<br>
> <br>
> <br>
> Yes, this is exactly the behavior I want.<br>
<br>
Well that is not something I would want to see implemented in hotspot.<br>
<br>
Cheers,<br>
David<br>
-----<br>
<br>
> Glavo<br>
> <br>
> On Tue, Jan 2, 2024 at 10:08 AM David Holmes <<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a> <br>
> <mailto:<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>>> wrote:<br>
> <br>
>     Hi Glavo,<br>
> <br>
>     On 24/12/2023 4:18 am, Glavo wrote:<br>
>      > Hi,<br>
>      ><br>
>      > There are already many Linux distributions that are following the<br>
>      > multiarch-spec[1] and adding the following paths to the default<br>
>     library<br>
>      > path list:<br>
>      ><br>
>      >   * /usr/local/lib/<triplet><br>
>      >   * /lib/<triplet><br>
>      >   * /usr/lib/<triplet><br>
>      ><br>
>      > But OpenJDK doesn't add these paths to the java.library.path by<br>
>     default,<br>
>      > so System.loadLibrary(String) has annoying behavior differences<br>
>     with ld.<br>
> <br>
>     AFAICS java.library.path (and sun.boot.library.path) are input<br>
>     properties that can be set by the user. There are no "default" values<br>
>     for these properties as such. The library loading will ultimately rely<br>
>     on the behaviour of dlopen, if no additional paths have been set, so it<br>
>     seems to me what you really want is for dlopen to act "the same way"<br>
>     that ld does. Note that dlopen will already check the contents of<br>
>     /etc/ld.so.cache<br>
> <br>
>      > Many libraries already installed on the system cannot be found by<br>
>      > System.loadLibrary(String).<br>
>      ><br>
>      > I wish OpenJDK would parse the /etc/ld.so.conf to get the full<br>
>     library<br>
>      > path list so it would be consistent with the behavior of ld.<br>
>      > Can anyone consider this suggestion?<br>
> <br>
>     This does not seem practical. On my system ld.so.conf just contains<br>
> <br>
>     include ld.so.conf.d/*.conf<br>
> <br>
>     so now we (hotspot) have to read the top-level file, parse it,<br>
>     interpret<br>
>     it and then recursively read, parse and interpret more files.<br>
> <br>
>     Cheers,<br>
>     David<br>
>     ----<br>
> <br>
> <br>
>      > Glavo<br>
>      ><br>
>      > [1]: <a href="https://wiki.ubuntu.com/MultiarchSpec" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/MultiarchSpec</a><br>
>     <<a href="https://wiki.ubuntu.com/MultiarchSpec" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/MultiarchSpec</a>><br>
>      > <<a href="https://wiki.ubuntu.com/MultiarchSpec" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/MultiarchSpec</a><br>
>     <<a href="https://wiki.ubuntu.com/MultiarchSpec" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/MultiarchSpec</a>>><br>
> <br>
</blockquote></div>