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

[Glavo]

>
> As for Panama, note that the SymbolLookup API allows a better way to
> load system libraries, with its SymbolLookup::libraryLookup factory:
>
>
> 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)
>
> This is essentially a "raw" wrapper around dlopen/dlsym. So, each name
> you can see in `ldconfig -p`, you will be able to load it with this method.
>

Thanks for the clarification.

As Sebastian mentioned, the process of loading system libraries is higly
> OS-dependent. On Linux, you have to wrestle with version numbers (e.g.
> GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system
> libraries are not even present in the file-system [1]. So, I'm afraid
> that loading a system library is a more involved process than just
> setting up a bunch of paths correctly - which might work in the 80%
> cases, but still fail in other cases. Overall, the general feeling is
> that System::loadLibrary tries to expose library loading in a
> minimum-common-denominator kind of approach (which is common to a lot of
> JDK APIs), and trying to make that mechanism more flexible might be a
> lost cause, or not have a great return on investment. The raw
> SymbolLookup wrapper shown above bypasses all these issues, and uses
> whatever library lookup mechanism the underlying OS prefers. Advanced
> users should definitively prefer the latter when working with system
> libraries (esp. when doing so using the FFM's Linker).
>

Well, it looks more difficult than I thought.
Maybe we could do something simpler, like just add those paths from the
multiarch specification to the default java.library.path.

Glavo

On Fri, Jan 5, 2024 at 11:02 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Glavo,
> parsing ld.conf is something that some frameworks do (e.g. JNR). Last
> time I checked there was some concerns in having hotspot bootstrap code
> depending on the results of an external tool, whose output could change
> over time. Currently, IIRC the list of path is just a compiler constant
> (a macro), which is altered on a per distro basis.
>
> As for Panama, note that the SymbolLookup API allows a better way to
> load system libraries, with its SymbolLookup::libraryLookup factory:
>
>
> 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)
>
> This is essentially a "raw" wrapper around dlopen/dlsym. So, each name
> you can see in `ldconfig -p`, you will be able to load it with this method.
>
> As Sebastian mentioned, the process of loading system libraries is higly
> OS-dependent. On Linux, you have to wrestle with version numbers (e.g.
> GL.so.3) which is not an issue on MacOS/Windows. On recent MacOS, system
> libraries are not even present in the file-system [1]. So, I'm afraid
> that loading a system library is a more involved process than just
> setting up a bunch of paths correctly - which might work in the 80%
> cases, but still fail in other cases. Overall, the general feeling is
> that System::loadLibrary tries to expose library loading in a
> minimum-common-denominator kind of approach (which is common to a lot of
> JDK APIs), and trying to make that mechanism more flexible might be a
> lost cause, or not have a great return on investment. The raw
> SymbolLookup wrapper shown above bypasses all these issues, and uses
> whatever library lookup mechanism the underlying OS prefers. Advanced
> users should definitively prefer the latter when working with system
> libraries (esp. when doing so using the FFM's Linker).
>
> Maurizio
>
> [1] -
>
> https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes
>
> On 04/01/2024 14:24, Glavo wrote:
> > This is the only way I can think of to get the JDK to behave
> > consistently with ld.
> > Maybe we should wait and see other developers who are more familiar
> > with this part.
> >
> > I'm now sending this email to panama-dev as well.
> > I think this proposal is of great significance to Panama, as it will
> > make it easier for developers to develop wrappers for platform libraries.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240106/06a59aea/attachment-0001.htm>