RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
Maurizio Cimadamore
mcimadamore at openjdk.org
Thu Mar 21 22:09:25 UTC 2024
On Mon, 18 Mar 2024 17:43:45 GMT, Suchismith Roy <sroy at openjdk.org> wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>
> trraling spaces
This problem seems relatively similar to what happens for versioned library names on e.g. linux distributions - e.g. "libclang.so.2". In such cases users are stuck between a rock and a hard place: using `System.loadLibrary("libclang")` is too little: it will be expanded to `libclang.so`, and will not be found. But there's no way to pass the version name to `loadLibrary`, as, to do that, you have to also pass the `.so` extension, and that doesn't work. So the only option is to use the _full_ absolute name with `System::load` (not `loadLibrary`).
My feeling is that it is not possible to "infer" the desired member name (because we don't know which version the member library has), in the same way as, in my system, it is not possible to infer "libc.so.6" from just the library name "c". As @JornVernee mentioned, this is why `SymbolLookup::libraryLookup` exists, so that library names can be passed straight to dlopen, w/o further interpretation from the JDK. It seems that at least part of the issue here is that the `jextract` code loads its own library (libclang) using `System::loadLibrary`, which doesn't do the right thing on AIX when only given "clang" as the library name. But I'm not exactly sure there's a fix for that at the `System::loadLibrary` level if `dlopen` really expects `clang.a(libclang.so.16)` to be passed as parameter.
In other words, a fix to `mapLibraryName` only works as long as `dlopen` on AIX is able to do something with a name that is mechanically inferred, such as `clang.a(libclang.so)`. Is that the case? (I'm pessimistic)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013909303
More information about the core-libs-dev
mailing list