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.
