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

[Martin Doerr]

On Thu, 21 Mar 2024 15:22:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello @suchismith1993, I haven't fully caught up on the necessity of this change. The current proposed change, renames files in the underlying filesystem in the code flow of `System.loadLibrary()` and I don't think is the right thing to do irrespective of whether we do it in AIX specific code or common code.
>> 
>> Could you update the JBS issue description to clearly explain what (application?) code is causing what issue? I know you mentioned about jextract here, but it's not clear whether this is some issue in jextract or something else. Having all those details in the JBS issue will be helpful to decide what changes should be pursued.
>
> As for this:
> 
>> Yes we are trying to install liblcang and also jextract and it fails with errors.
> 
>> Exception in thread "main" java.lang.UnsatisfiedLinkError: no clang in java.library.path
>>
>     at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2439)
>     at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916)
>     at java.base/java.lang.System.loadLibrary(System.java:2063)
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362))
>     at [org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract at 22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174))
> 
> 
> I had a quick look at the latest jextract code and I don't see some of the classes that are reported in that stacktrace. Which exact version of jextract is this? If jextract is what motivated this change, then I would recommend checking on jextract-dev mailing list first https://mail.openjdk.org/mailman/listinfo/jextract-dev to understand if this is an issue in jextract itself.

I had experimented with the jdk22 branch of jextract. AIX is currently not supported. `libclang.a(libclang.so.16)` only severs as an example use case. However, archives which require a member specification seem to be quite common on AIX. So, not supporting them is a major limitation for the foreign function interface. We need to discuss which formats should be supported by `System.loadLibrary`:

- `System.loadLibrary("clang(libclang.so.16)")`
- `System.loadLibrary("clang.a(libclang.so.16)")`
- `System.loadLibrary("libclang.a(libclang.so.16)")`

I think the first variant should be supported. Maybe not the others?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534172694