RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]

[Suchismith Roy]

On Thu, 21 Mar 2024 22:04:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> 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)

Yes, dlopen expects the full name. 
If i just pass clang in loadLibrary() and not the member i get exec error. 
System error: Exec format error

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014780371