On Mon, 18 Mar 2024 17:43:45 GMT, Suchismith Roy <s...@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

Reply via email to