> > 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.cimadam...@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. >
