On Thu, 21 Mar 2024 22:04:28 GMT, Maurizio Cimadamore <[email protected]>
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
