On Thu, 21 Mar 2024 15:22:22 GMT, Jaikiran Pai <j...@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@22/org.openjdk.jextract.clang.libclang.RuntimeHelper.<clinit>(RuntimeHelper.java:65)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.RuntimeHelper.%3cclinit%3e(RuntimeHelper.java:65)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.constants$17.<clinit>(constants$17.java:46)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.constants$17.%3cclinit%3e(constants$17.java:46)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion$MH(Index_h.java:5690)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_getClangVersion(Index_h.java:5698)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.LibClang.version(LibClang.java:93)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run(JextractTool.java:362)) > at > [org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main(JextractTool.java:174)](mailto:org.openjdk.jextract@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
