On Thu, 21 Mar 2024 15:51:59 GMT, Suchismith Roy <s...@openjdk.org> wrote:
>>> Do you mean some application code is calling the `System.loadLibrary()` >>> method with such values? >> >> 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)) >> >> >> The actual member is libclang.a(libclang.so.16) > >> 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. > > This is not specific to an application. We are looking to support member > objects of AIX shared libraries in the Java ClassLoader. > As for the renaming, the renaming is necessary because the member object is > not part of the actual filename. > Example : libclang.a(libclang.so.16) > This member object, is identified only by the dlopen() in the hotspot code. > But there is no actual file named libclang.a(libclang.so.16) in the > filesystem. > So when the check is done if file exists, it fails,i.e it checks for > libclang.a(libclang.so.16).So i remove the braces and member name to extract > the actual name of the file in the filesystem, which is libclang.a. But when > we pass libclang.a to the dlopen ,it will fail to open it. > Hence i need to rename the file to the name with braces before it passes to > dlopen.So i reconstruct it to libclang.a(libclang.so.16) > 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. Jextract is one use case that prompted to make this change. There is no issue with the Jextract in particular. We probably might need a small change in the Index java file. But there are use cases where we need to support AIX dynamic archives to be able to load using Java ClassLoader,which is more like a front end to the hotspot code. This support got recently added to hotspot code too. It is important to have it at the classloader level too. @JoKern65 Could you add in more on the importance of this and provide your inputs ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534221275
