<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">As for Panama, note that the SymbolLookup API allows a better way to<br>load system libraries, with its SymbolLookup::libraryLookup factory:<br><br><a href="https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)" rel="noreferrer" target="_blank">https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)</a><br><br>This is essentially a "raw" wrapper around dlopen/dlsym. So, each name<br>you can see in `ldconfig -p`, you will be able to load it with this method.<br></blockquote><div><br></div><div>Thanks for the clarification.</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">As Sebastian mentioned, the process of loading system libraries is higly<br>OS-dependent. On Linux, you have to wrestle with version numbers (e.g.<br>GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system<br>libraries are not even present in the file-system [1]. So, I'm afraid<br>that loading a system library is a more involved process than just<br>setting up a bunch of paths correctly - which might work in the 80%<br>cases, but still fail in other cases. Overall, the general feeling is<br>that System::loadLibrary tries to expose library loading in a<br>minimum-common-denominator kind of approach (which is common to a lot of<br>JDK APIs), and trying to make that mechanism more flexible might be a<br>lost cause, or not have a great return on investment. The raw<br>SymbolLookup wrapper shown above bypasses all these issues, and uses<br>whatever library lookup mechanism the underlying OS prefers. Advanced<br>users should definitively prefer the latter when working with system<br>libraries (esp. when doing so using the FFM's Linker).<br></blockquote><div><br></div><div>Well, it looks more difficult than I thought.<br></div><div>Maybe we could do something simpler, like just add those paths from the multiarch specification to the default java.library.path.<br></div><div><br></div><div>Glavo</div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 5, 2024 at 11:02 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@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">Hi Glavo,<br>
parsing ld.conf is something that some frameworks do (e.g. JNR). Last <br>
time I checked there was some concerns in having hotspot bootstrap code <br>
depending on the results of an external tool, whose output could change <br>
over time. Currently, IIRC the list of path is just a compiler constant <br>
(a macro), which is altered on a per distro basis.<br>
<br>
As for Panama, note that the SymbolLookup API allows a better way to <br>
load system libraries, with its SymbolLookup::libraryLookup factory:<br>
<br>
<a href="https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)" rel="noreferrer" target="_blank">https://download.java.net/java/early_access/jdk22/docs/api/java.base/java/lang/foreign/SymbolLookup.html#libraryLookup(java.lang.String,java.lang.foreign.Arena)</a><br>
<br>
This is essentially a "raw" wrapper around dlopen/dlsym. So, each name <br>
you can see in `ldconfig -p`, you will be able to load it with this method.<br>
<br>
As Sebastian mentioned, the process of loading system libraries is higly <br>
OS-dependent. On Linux, you have to wrestle with version numbers (e.g. <br>
GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system <br>
libraries are not even present in the file-system [1]. So, I'm afraid <br>
that loading a system library is a more involved process than just <br>
setting up a bunch of paths correctly - which might work in the 80% <br>
cases, but still fail in other cases. Overall, the general feeling is <br>
that System::loadLibrary tries to expose library loading in a <br>
minimum-common-denominator kind of approach (which is common to a lot of <br>
JDK APIs), and trying to make that mechanism more flexible might be a <br>
lost cause, or not have a great return on investment. The raw <br>
SymbolLookup wrapper shown above bypasses all these issues, and uses <br>
whatever library lookup mechanism the underlying OS prefers. Advanced <br>
users should definitively prefer the latter when working with system <br>
libraries (esp. when doing so using the FFM's Linker).<br>
<br>
Maurizio<br>
<br>
[1] - <br>
<a href="https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes" rel="noreferrer" target="_blank">https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes</a><br>
<br>
On 04/01/2024 14:24, Glavo wrote:<br>
> This is the only way I can think of to get the JDK to behave <br>
> consistently with ld.<br>
> Maybe we should wait and see other developers who are more familiar <br>
> with this part.<br>
><br>
> I'm now sending this email to panama-dev as well.<br>
> I think this proposal is of great significance to Panama, as it will <br>
> make it easier for developers to develop wrappers for platform libraries.<br>
</blockquote></div>