Integrated: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object
On Wed, 21 Feb 2024 11:32:41 GMT, Suchismith Roy 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) This pull request has now been integrated. Changeset: 4895a15a Author:Suchismith Roy Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/4895a15a779fab70290b4df3b464d79a14937e28 Stats: 149 lines in 2 files changed: 149 ins; 0 del; 0 mod 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object Reviewed-by: mdoerr, mchung - PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v25]
On Mon, 15 Apr 2024 13:58:38 GMT, Jaikiran Pai wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Files copy > > I'll let Mandy and others familiar with this area and AIX do the formal > review of this PR. My involvement here was merely general inputs. Thank you @jaikiran @mlchung @TheRealMDoerr Got to learn about new ways to test and learnt about the classloader functionalities better. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2061282909
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v29]
> 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: Update LoadAIXLibraryFromArchiveObject.java Nits,coding style and variable name - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/2b729673..53343781 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=28 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=27-28 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v27]
On Wed, 17 Apr 2024 10:42:46 GMT, Martin Doerr wrote: > Please take a look at Mandy's suggestions. I think they make sense. Done. Sorry i missed it. I got notified that the patch had got approved so i went ahead with integrate. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2060978059
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v28]
> 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 two additional commits since the last revision: - Update test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java remove final Co-authored-by: Mandy Chung - Update test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java remove final Co-authored-by: Mandy Chung - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/12270d06..2b729673 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=27 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=26-27 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v25]
On Mon, 15 Apr 2024 14:06:54 GMT, Martin Doerr wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Files copy > > test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java > line 71: > >> 69: } >> 70: } >> 71: } > > I think files typically have a newline at the end. In ClassLoader i didnt see it. Put newline at end for both files now - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566037066
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v13]
On Mon, 15 Apr 2024 14:05:24 GMT, Martin Doerr wrote: >> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 40: >> >>> 38: * This method returns false so that loading of shared library >>> continues if >>> 39: * libname.so is not present. >>> 40: */ >> >> The '*' should be in the same column. Please compare to >> ClassLoaderHelper.java for other OSs. > > '*' should are in the same column, now, but it is still not the same coding > style as in other files. Why can't you do it exactly like > https://github.com/openjdk/jdk/blob/273df6286a9cc4dcef4cd339234206b2ad922386/src/java.base/unix/classes/jdk/internal/loader/ClassLoaderHelper.java#L43 > ? Thanks. I didn't notice the one extra space. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566037541
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v27]
> 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 three additional commits since the last revision: - new line - spaces fix - spaces fix - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/de7f3a72..12270d06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=26 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=25-26 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v26]
> 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: coding style - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/f0672e76..de7f3a72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=25 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=24-25 Stats: 23 lines in 2 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v25]
On Mon, 15 Apr 2024 14:48:54 GMT, Magnus Ihse Bursie wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Files copy
>
> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 42:
>
>> 40: */
>> 41: static boolean loadLibraryOnlyIfPresent() {
>> 42: return true;
>
> I've been following this PR to and fro for a while, so I might have missed
> something. But it looks like the code and the documentation is completely at
> odds -- the documentation claims the function should return `false`, but in
> reality it returns `true`. If the code is correct, the documentation needs to
> be fixed or clarified.
It was a wrong push. Sorry. The autocomplete command was causing some troubles.
I had changed it in local to see if the jtreg test fails.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1566023166
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v25]
On Mon, 15 Apr 2024 13:36:17 GMT, Jaikiran Pai wrote: > The test seems to be working fine then based on the output you noted. It > catches the issue (by failing) when the source change proposed in this PR is > absent and then verifies the change works as expected (by passing). Yes. Passes when reverting back. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056916358
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
On Mon, 15 Apr 2024 13:00:57 GMT, Jaikiran Pai wrote: > > Thanks. I tried with a different shared object. > > If you undo the changes that are being proposed in this PR in the > `src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java` class > (only undo that class changes), then rebuild the JDK and rerun this newly > introduced test, what exception/failure do you see in the test? Don't push > the changes, it's merely an exercise to ascertain that the test you are > introducing will indeed verify the changes that you have done to support > loading library from an archive object through System.loadLibrary(). attempting to load library foobar Exception in thread "main" java.lang.UnsatisfiedLinkError: no foobar in java.library.path: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2442) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2068) at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:67) STDERR: stdout: [attempting to load library foobar ]; stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: no foobar in java.library.path: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2442) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2068) at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:67) ] exitValue = 1 java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1] at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:521) at LoadAIXLibraryFromArchiveObject.main(LoadAIXLibraryFromArchiveObject.java:61) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575) JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1] JavaTest Message: shutting down test After setting loadLibraryOnlyIfPresent to true again. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056857173
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v25]
> 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: Files copy - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/f7ef9b04..f0672e76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=24 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=23-24 Stats: 26 lines in 1 file changed: 23 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v24]
> 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: Files copy - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/22cd52d7..f7ef9b04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=23 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=22-23 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
On Mon, 15 Apr 2024 08:30:57 GMT, Suchismith Roy wrote: >>> > Thanks! This looks like a good idea. Only the directory handling needs >>> > some modification. This version tries to load >>> > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", >>> > but it should load >>> > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". >>> >>> > Thanks! This looks like a good idea. Only the directory handling needs >>> > some modification. This version tries to load >>> > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", >>> > but it should load >>> > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". >>> >>> I am facing the same error. But i do not understand why is it resolved to >>> libawt_headless.so . >> >> stdout: [attempting to load library foobar >> ]; >> stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't >> load library: >> /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so >> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406) >> at java.base/java.lang.Runtime.load0(Runtime.java:852) >> at java.base/java.lang.System.load(System.java:2030) >> at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) >> at >> java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) >> at >> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197) >> at >> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139) >> at >> java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259) >> at >> java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:251) >> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435) >> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) >> at java.base/java.lang.System.loadLibrary(System.java:2068) >> at >> LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52) >> ] >> exitValue = 1 > >> > > Thanks! This looks like a good idea. Only the directory handling needs >> > > some modification. This version tries to load >> > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", >> > > but it should load >> > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". >> > >> > >> > > Thanks! This looks like a good idea. Only the directory handling needs >> > > some modification. This version tries to load >> > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", >> > > but it should load >> > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". >> > >> > >> > I am facing the same error. But i do not understand why is it resolved to >> > libawt_headless.so . >> >> stdout: [attempting to load library foobar ]; stderr: [Exception in thread >> "main" java.lang.UnsatisfiedLinkError: Can't load library: >> /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so >> at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406) at >> java.base/java.lang.Runtime.load0(Runtime.java:852) at >> java.base/java.lang.System.load(System.java:2030) at >> java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at >> java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) >> at >> java.base/jdk.internal.loader.NativeL
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v23]
> 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: Use ProcessTool to use scratch space for archives. - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/3cd8bd1a..22cd52d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=22 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=21-22 Stats: 62 lines in 1 file changed: 25 ins; 24 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
On Thu, 11 Apr 2024 18:29:36 GMT, Suchismith Roy wrote: > > > Thanks! This looks like a good idea. Only the directory handling needs > > > some modification. This version tries to load > > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", > > > but it should load > > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". > > > > > > > Thanks! This looks like a good idea. Only the directory handling needs > > > some modification. This version tries to load > > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", > > > but it should load > > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". > > > > > > I am facing the same error. But i do not understand why is it resolved to > > libawt_headless.so . > > stdout: [attempting to load library foobar ]; stderr: [Exception in thread > "main" java.lang.UnsatisfiedLinkError: Can't load library: > /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406) at > java.base/java.lang.Runtime.load0(Runtime.java:852) at > java.base/java.lang.System.load(System.java:2030) at > java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at > java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) > at > java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197) > at > java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139) > at > java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259) > at java.base/jdk.internal.loader.NativeLibra ries.loadLibrary(NativeLibraries.java:251) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2068) at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52) ] exitValue = 1 @jaikiran I see it is attempting to load foobar. But for some reason it is referring to different .so file. Some issue with usage of ProcessTools/ProcessBuilder ? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2056171132
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
On Thu, 11 Apr 2024 17:08:49 GMT, Suchismith Roy wrote: > > Thanks! This looks like a good idea. Only the directory handling needs some > > modification. This version tries to load > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", > > but it should load > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". > > > Thanks! This looks like a good idea. Only the directory handling needs some > > modification. This version tries to load > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", > > but it should load > > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". > > I am facing the same error. But i do not understand why is it resolved to > libawt_headless.so . stdout: [attempting to load library foobar ]; stderr: [Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix_LoadAIXLibraryFromArchiveObject_java/scratch/0/native/libawt_headless.so at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2406) at java.base/java.lang.Runtime.load0(Runtime.java:852) at java.base/java.lang.System.load(System.java:2030) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:331) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:197) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:259) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:251) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2435) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:916) at java.base/java.lang.System.loadLibrary(System.java:2068) at LoadAIXLibraryFromArchiveObject$LoadLibraryApp.main(LoadAIXLibraryFromArchiveObject.java:52) ] exitValue = 1 - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2050279516
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy 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:
>
> Files copy method
`String libraryName = "awt";
File awtSharedObjectPathCopy = new File("/test/lib/libawt.so");
File awtSharedObjectPath = new File("/test/lib/libawt.so");
File awtArchivePath = new File("/test/lib/libawt.a");
awtSharedObjectPath.renameTo(awtArchivePath);
if (awtSharedObjectPath.exists()) {
awtSharedObjectPath.renameTo(awtSharedObjectPathCopy);
throw new RuntimeException("LoadAIXLibraryFromArchiveObject: .so
should not exist.");
`
@jaikiran is this also right way to use the /test/lib directory ?
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2050149972
Re: RFR: 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy 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: > > Files copy method > Thanks! This looks like a good idea. Only the directory handling needs some > modification. This version tries to load > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", > but it should load > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". > Thanks! This looks like a good idea. Only the directory handling needs some > modification. This version tries to load > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/scratch/0/native/libawt_headless.so", > but it should load > "test-support/jtreg_test_jdk_java_lang_RuntimeTests_loadLibrary_aix/java/lang/RuntimeTests/loadLibrary/aix/AIXLoadLibraryDriver/native/libfoobar.a". I am facing the same error. But i do not understand why is it resolved to libawt_headless.so . - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2050138340
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
On Wed, 10 Apr 2024 16:46:30 GMT, Suchismith Roy 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:
>
> Files copy method
> BUILD_JDK_JTREG_OUTPUT_DIR
I agree. How can i fetch this path ? I tried
System.getEnv("BUILD_JDK_JTREG_OUTPUT_DIR") But it doesn't seem to work.
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2048167273
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v22]
> 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: Files copy method - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/488779a4..3cd8bd1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=21 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=20-21 Stats: 18 lines in 1 file changed: 2 ins; 15 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v21]
On Wed, 10 Apr 2024 15:40:02 GMT, Martin Doerr wrote: > JTREG usually places libraries here: > > https://github.com/openjdk/jdk/blob/279ed0ddd505fb3052b818f755b4b220ed5557e6/make/test/JtregNativeJdk.gmk#L47 > > > Files can get copied by `Files.copy`: > https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#copy-java.nio.file.Path-java.nio.file.Path-java.nio.file.CopyOption...- I have referred to the lib directory under jdk and not jtreg anymore. Wouldn't that be fine ? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2048007327
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v21]
> 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: test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/33257fe5..488779a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=20 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=19-20 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v20]
> 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: test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/cab78e37..33257fe5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=19 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=18-19 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v19]
> 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: test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/d2f040b1..cab78e37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=18 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=17-18 Stats: 23 lines in 1 file changed: 14 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v18]
> 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 two additional commits since the last revision: - test change - test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/f0459fc3..d2f040b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=17 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=16-17 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v17]
On Mon, 8 Apr 2024 19:45:14 GMT, Martin Doerr wrote:
>> Suchismith Roy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> test change
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> line 36:
>
>> 34: String libraryName = "awt";
>> 35: File awtSharedObjectPath = new File("/test/lib/libawt.so");
>> 36: File awtArchivePath = new File("/test/lib/libawt.a");
>
> How does this work? Did you create a "/test" directory? I don't have it on my
> machine.
I am not 100% sure. I think it is a temporary directory under jtreg. I referred
to the other test under loadLibrary. @mlchung Could you clarify this ?
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> line 37:
>
>> 35: File awtSharedObjectPath = new File("/test/lib/libawt.so");
>> 36: File awtArchivePath = new File("/test/lib/libawt.a");
>> 37: awtSharedObjectPath.renameTo(awtArchivePath);
>
> This should work for this test. But, what if an AWT test gets executed after
> your test? I think copy is safer than renaming.
Maybe i need to rename it back. If we just copy, it would take the .so itself,
so we cant enforce it.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1557366150
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1557365063
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v17]
> 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: test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/42820306..f0459fc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=16 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=15-16 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v16]
> 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: test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/66dc630a..42820306 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=15 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=14-15 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v15]
> 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: test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/1746f554..66dc630a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=14 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=13-14 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v14]
> 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: test change - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/89b8da39..1746f554 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=13 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=12-13 Stats: 11 lines in 2 files changed: 1 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 AIX System::loadLibrary needs support to load a shared library from an archive object [v13]
On Fri, 5 Apr 2024 18:14:36 GMT, Suchismith Roy 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 three > additional commits since the last revision: > > - update tests > - update tests > - update tests Ok. How can i get the path of an existing .so file and renamed it to .a ? Example we have libawt.so. In order to rename it i need to find its path. How can i do that using Java code ? Do i need to parse the java library path and search in it ? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2043232272
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v13]
> 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 three additional commits since the last revision: - update tests - update tests - update tests - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/68eb14e6..89b8da39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=12 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=11-12 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v12]
On Fri, 5 Apr 2024 17:38:50 GMT, Mandy Chung wrote:
>> Suchismith Roy has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - update tests
>> - update tests
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> line 37:
>
>> 35: File perfstatSharedObjectPath = new
>> File("/usr/lib/libperfstat.so");
>> 36: // If .a file is not present and .so file is present.
>> 37: if (!perfstatPath.exists() || !perfstatSharedObjectPath.exists())
>
> This test does not compile. Please run it before and after the fix to
> validate the fix.
>
> Suggestion:
>
> if (!perfstatArchivePath.exists() ||
> !perfstatSharedObjectPath.exists())
Yes, sorry it was the autocomplete command that ran through.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1554048830
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v11]
On Fri, 5 Apr 2024 16:18:11 GMT, Mandy Chung wrote:
>> Suchismith Roy has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - spaces
>> - nits and move file to aix directory
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> line 33:
>
>> 31: public class LoadAIXLibraryFromArchiveObject {
>> 32: public static void main(String[] args) throws Exception {
>> 33: String libraryName = "perfstat";
>
> I suggest to check if `/usr/lib/libperstat.a` is present and
> `/usr/lib/libperfstat.so` is not present; otherwise, the test should throw
> RuntimeException.
I understand. But isn't the presence of .so also a legit test case ? I mean
loadLibrary is not expected to fail if that happens. The failure is expected
when .so is not present and .a is also not present . Shouldn't we check for non
existence of both ?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1554048115
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v12]
> 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 two additional commits since the last revision: - update tests - update tests - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/5f05e278..68eb14e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=11 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=10-11 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v11]
On Fri, 5 Apr 2024 08:58:34 GMT, Suchismith Roy 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 two additional
> commits since the last revision:
>
> - spaces
> - nits and move file to aix directory
Wouldn't hotspot anyways give a failure which will lead to an exception if
.a is not present ?
On Fri, Apr 5, 2024, 21:48 Mandy Chung ***@***.***> wrote:
> ***@***. commented on this pull request.
> --
>
> In
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> <https://github.com/openjdk/jdk/pull/17945#discussion_r1553959163>:
>
> > + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License version
> + * 2 along with this work; if not, write to the Free Software Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +/**
> + * @test
> + * @bug 8319516
> + * @requires os.family == "aix"
> + * @run main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX
>
> ⬇️ Suggested change
>
> - * @run main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX
> + * @run main/othervm -Djava.library.path=/usr/lib
> LoadAIXLibraryFromArchiveObject
>
> --
>
> In
> test/jdk/java/lang/RuntimeTests/loadLibrary/aix/LoadAIXLibraryFromArchiveObject.java
> <https://github.com/openjdk/jdk/pull/17945#discussion_r1553962707>:
>
> > + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
> + * or visit www.oracle.com if you need additional information or have any
> + * questions.
> + */
> +
> +/**
> + * @test
> + * @bug 8319516
> + * @requires os.family == "aix"
> + * @run main/othervm -Djava.library.path=/usr/lib LoadLibraryTestAIX
> + */
> +
> +public class LoadAIXLibraryFromArchiveObject {
> +public static void main(String[] args) throws Exception {
> +String libraryName = "perfstat";
>
> I suggest to check if /usr/lib/libperstat.a is present and
> /usr/lib/libperfstat.so is not present; otherwise, the test should throw
> RuntimeException.
> --
>
> In test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java
> <https://github.com/openjdk/jdk/pull/17945#discussion_r1553961921>:
>
> > +} catch (Exception e) {
> +throw new RuntimeException("LoadLibraryTestAIX : could not load
> libperfstat.a"+e);
> +}
>
> In this case, the test can verify if /usr/lib/libperstat.a is present and
> /usr/lib/libperfstat.so is not present; otherwise, the test should throw
> RuntimeException. This also serves a good documentation purpose showing
> what this test expects.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/17945#pullrequestreview-1983652464>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AESW3BGWJOY5EQDRKPNMKEDY33FGFAVCNFSM6ABDS326YOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSOBTGY2TENBWGQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2040275014
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v11]
> 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 two additional commits since the last revision: - spaces - nits and move file to aix directory - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/0f6641fb..5f05e278 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=10 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=09-10 Stats: 82 lines in 3 files changed: 38 ins; 40 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v10]
On Thu, 4 Apr 2024 17:38:31 GMT, Mandy Chung wrote:
>> test/jdk/java/lang/RuntimeTests/loadLibrary/LoadLibraryTestAIX.java line 38:
>>
>>> 36: } catch (Exception e) {
>>> 37: throw new RuntimeException("LoadLibraryTestAIX : could not
>>> load libperfstat.a"+e);
>>> 38: }
>>
>> Nit: the catch clause is not strictly needed. `UnsatisfiedLinkError` is an
>> unchecked exception. The test should fail if you run it with JDK without
>> this fix.
>
> The test should verify if `/usr/lib/libperstat.a` is present and also
> `/usr/lib/libperfstat.so` is not present.
>
> Do you expect all AIX machines do not have `/usr/lib/libperfstat.so`?
Yes it is expected. the hotspot code has harcoded it to .a file.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1553156812
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v10]
On Thu, 4 Apr 2024 11:13:43 GMT, Suchismith Roy 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: > > Add jtreg test case Is the current name of file accurate ? Shall i just make a directory named aix and keep the name of file as loadLibraryTest. Just trying to get familiar with the best practices. On Thu, Apr 4, 2024, 21:45 Mandy Chung ***@***.***> wrote: > Under test/jdk/java/lang/RuntimeTests/loadLibrary directory or a > subdirectory under it would work > > — > Reply to this email directly, view it on GitHub > <https://github.com/openjdk/jdk/pull/17945#issuecomment-2037641298>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AESW3BDXY2NTWOZO2OTRQRTY3V4DLAVCNFSM6ABDS326YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGY2DCMRZHA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2037708525
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v9]
On Thu, 4 Apr 2024 10:43:35 GMT, Suchismith Roy wrote: >> Hotspot loads it like this: >> https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/hotspot/os/aix/libperfstat_aix.cpp#L76 >> Are you sure it is supposed to be loaded without member specification? > >> Hotspot loads it like this: >> >> https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/hotspot/os/aix/libperfstat_aix.cpp#L76 >> >> >> Are you sure it is supposed to be loaded without member specification? > > Yes i was able to do it without mentioning the shared object. libodm was > failing though. > > > Hello @suchismith1993, > > > > Usually there is not such pure .a files that comes packaged with the > > > > OS. They are provided by some applications. So i am not sure how i can > > > > make the tests consistent for such cases. > > > > Do you have any suggestions here ? > > > > > > > > > Within the JDK repo, some tests require test specific native libraries > > > (like in your case here). It appears that the JDK build infrastructure > > > has ability to compile native code (`foo.c` for example) into a native > > > library. However that build infrastructure doesn't appear to be flexible > > > enough to support the case where you would have to run AIX specific > > > commands to generate a `.a` file. So the approach of generating a test > > > specific `.a` file doesn't look promising right now (it could still be > > > possible, but I don't know how big a build change that would require). > > > So taking a step back - I see that > > > https://bugs.openjdk.org/browse/JDK-8313616 introduced the ability to > > > dealing with `.a` files on AIX from within the hotspot area. In that > > > commit https://github.com/openjdk/jdk/pull/15204/files I see that there > > > are references to a couple of `.a` files - for example `libodm.a` and > > > `libperfstat.a`. Are those `.a` expected to be present on certain AIX > > > systems? Perhaps your new test could use either of those in the test? > > > There was also a mention of `libclang.a` on AIX, previously in this > > > discussion. Maybe that could be used in the test? > > > > > > I found libperfstat as the only example that is purely an archive files as > > part of AIX, after trying out multiple archives under /usr/lib. I am facing > > an issue to run the test ,but unable to set the library path to /usr/lib. I > > see the existing test case has libawt as part of jdk itself . Can i set > > -Djava.library.path while running jtreg test case ? > > -Djava.library.path=/home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/images/test/jdk/jtreg/native > I see from logs, this is the path being set to, Which is not the intended > path. Not sure how the other test is working. Ok i think i was able to resolve this. Need some guidance on where should i place the test file. Have made a very basic test to just load libperfstat.a - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036882540
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v10]
> 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: Add jtreg test case - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/c6ec69a9..0f6641fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=09 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=08-09 Stats: 40 lines in 1 file changed: 40 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v9]
On Thu, 4 Apr 2024 10:30:08 GMT, Martin Doerr wrote: > Hotspot loads it like this: > > https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/hotspot/os/aix/libperfstat_aix.cpp#L76 > > > Are you sure it is supposed to be loaded without member specification? Yes i was able to do it without mentioning the shared object. libodm was failing though. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036822196
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]
On Thu, 4 Apr 2024 09:41:50 GMT, Suchismith Roy wrote: > > Hello @suchismith1993, > > > Usually there is not such pure .a files that comes packaged with the OS. > > > They are provided by some applications. So i am not sure how i can make > > > the tests consistent for such cases. > > > Do you have any suggestions here ? > > > > > > Within the JDK repo, some tests require test specific native libraries > > (like in your case here). It appears that the JDK build infrastructure has > > ability to compile native code (`foo.c` for example) into a native library. > > However that build infrastructure doesn't appear to be flexible enough to > > support the case where you would have to run AIX specific commands to > > generate a `.a` file. So the approach of generating a test specific `.a` > > file doesn't look promising right now (it could still be possible, but I > > don't know how big a build change that would require). > > So taking a step back - I see that > > https://bugs.openjdk.org/browse/JDK-8313616 introduced the ability to > > dealing with `.a` files on AIX from within the hotspot area. In that commit > > https://github.com/openjdk/jdk/pull/15204/files I see that there are > > references to a couple of `.a` files - for example `libodm.a` and > > `libperfstat.a`. Are those `.a` expected to be present on certain AIX > > systems? Perhaps your new test could use either of those in the test? There > > was also a mention of `libclang.a` on AIX, previously in this discussion. > > Maybe that could be used in the test? > > I found libperfstat as the only example that is purely an archive files as > part of AIX, after trying out multiple archives under /usr/lib. I am facing > an issue to run the test ,but unable to set the library path to /usr/lib. I > see the existing test case has libawt as part of jdk itself . Can i set > -Djava.library.path while running jtreg test case ? -Djava.library.path=/home/hotspot/openjdk/jdk-suchi/jdk1/build/aix-ppc64-server-fastdebug/images/test/jdk/jtreg/native I see from logs, this is the path being set to, Which is not the intended path. Not sure how the other test is working. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036730865
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]
On Wed, 3 Apr 2024 07:35:46 GMT, Suchismith Roy wrote: >> Hello @suchismith1993, >> >>> > I adjust the comments which also answer your question. Please add an >>> > AIX-only test to verify this behavior. >>> >>> By test you mean provide the use case for pure .a files ? >> >> In the JDK repo, changes like these are backed by jtreg tests >> https://openjdk.org/guide/#jtreg. So for this change, you would need to add >> a jtreg test which only runs on AIX (the jtreg documentation explains how to >> do that) and will exercise the `System.loadLibrary` call for a AIX specific >> library and verify that the library can be loaded as per the expectations >> that are set in the changes proposed and finalized in this PR. >> >> For example, the test should verify that, after the changes proposed in this >> PR, calling `System.loadLibrary()` on AIX will load from >> `.a` if `.so` is absent. >> >> For reference, you can take a look at the existing tests for loadLibrary in >> the `test/jdk/java/lang/RuntimeTests/loadLibrary` directory. > >> test/jdk/java/lang/RuntimeTests/loadLibrary > > I see. Thank you. Got to check some test cases files and how they are > structured. > For this case, i feel the use case would be to have a pure .a file. Usually > there is not such pure .a files that comes packaged with the OS. They are > provided by some applications. So i am not sure how i can make the tests > consistent for such cases. > Do you have any suggestions here ? We are anyways passing it down to the > hotspot code , which is taking care of it. > Hello @suchismith1993, > > > Usually there is not such pure .a files that comes packaged with the OS. > > They are provided by some applications. So i am not sure how i can make the > > tests consistent for such cases. > > Do you have any suggestions here ? > > Within the JDK repo, some tests require test specific native libraries (like > in your case here). It appears that the JDK build infrastructure has ability > to compile native code (`foo.c` for example) into a native library. However > that build infrastructure doesn't appear to be flexible enough to support the > case where you would have to run AIX specific commands to generate a `.a` > file. So the approach of generating a test specific `.a` file doesn't look > promising right now (it could still be possible, but I don't know how big a > build change that would require). > > So taking a step back - I see that > https://bugs.openjdk.org/browse/JDK-8313616 introduced the ability to dealing > with `.a` files on AIX from within the hotspot area. In that commit > https://github.com/openjdk/jdk/pull/15204/files I see that there are > references to a couple of `.a` files - for example `libodm.a` and > `libperfstat.a`. Are those `.a` expected to be present on certain AIX > systems? Perhaps your new test could use either of those in the test? There > was also a mention of `libclang.a` on AIX, previously in this discussion. > Maybe that could be used in the test? I found libperfstat as the only example that is purely an archive files as part of AIX, after trying out multiple archives under /usr/lib. I am facing an issue to run the test ,but unable to set the library path to /usr/lib. I see the existing test case has libawt as part of jdk itself . Can i set -Djava.library.path while running jtreg test case ? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2036696638
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v9]
> 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: coding style - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/1ad4b33d..c6ec69a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=08 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=07-08 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]
On Tue, 2 Apr 2024 08:36:15 GMT, Jaikiran Pai wrote: > test/jdk/java/lang/RuntimeTests/loadLibrary I see. Thank you. Got to check some test cases files and how they are structured. For this case, i feel the use case would be to have a pure .a file. Usually there is not such pure .a files that comes packaged with the OS. They are provided by some applications. So i am not sure how i can make the tests consistent for such cases. Do you have any suggestions here ? We are anyways passing it down to the hotspot code , which is taking care of it. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2033773591
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]
On Mon, 1 Apr 2024 18:27:45 GMT, Mandy Chung wrote: > I adjust the comments which also answer your question. Please add an AIX-only > test to verify this behavior. By test you mean provide the use case for pure .a files ? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2031357165
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v8]
> 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: spaces - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/92e35692..1ad4b33d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=07 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v7]
> 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: remove .so to .a mapping - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/4c068e78..92e35692 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=06 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=05-06 Stats: 29 lines in 1 file changed: 5 ins; 14 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v6]
On Thu, 28 Mar 2024 16:57:59 GMT, Mandy Chung wrote:
> `System::loadLibrary("systeminfo")` should call `JVM_LoadLibrary` with
> "/usr/lib/libsysteminfo.so" argument (let the .a file exists under
> "/usr/lib") which in turn calls `os::dll_load`. JDK-8320005 changed
> `os::dll_load` to first load the given filename; if fails, it will call
> `dll_load_library` with "/usr/lib/libsysteminfo.a".
>
> You can turn on `-Xlog:library` and it should print log message loading
> "/usr/lib/libsysteminfo.so" if you have `loadLibraryOnlyIfPresent` to return
> false. If you don't see log message loading "/usr/lib/libsysteminfo.so",
> `loadLibraryOnlyIfPresent` still returns true.
>
> Turn on "-Xlog:os" should print "attempting shared library load of
> /usr/lib/libsysteminfo.so" and "attempting shared library load of
> /usr/lib/libsysteminfo.a" log message.
@mlchung That should work, but then the mapAlternateName is called in
NativeLibraries.java . I think the classloaderhelper for the respective
platform needs to implement it. So if i remove mapAlternateName I need to
probably remove the entire file from AIX, so that the classloaderhelper of unix
is referred.
Also in ClassLoaderHelper of unix, the mapAlternateName return null. So should
i keep it that way ?
Other optioon is to set loadLibraryOnlyIfPresent to false in the unix
classloaderhelper ? I am not sure if that would be allowed.
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2029530668
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:34:22 GMT, Mandy Chung wrote: >> libsystemInfo.a is one use case ,i got after discussion with our teams, >> which actually raised this issue in J9. So there are cases where pure .a >> files exist. > > AFAICT from your fix for > [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) commit > [e85355ad](https://github.com/openjdk/jdk/commit/e85355ada4ac1061c49ee9f1247d37a437c7b5ab). > > But it needs verification as I suggest (see > https://github.com/openjdk/jdk/pull/17945#issuecomment-2019965401). @mlchung [JDK-8320005](https://bugs.openjdk.org/browse/JDK-8320005) is solving the .so to .a mapping at hotspot level. But if we still call loadLibrary() , with a .so, which has an equivalent .a file, it will fail. What kind of verification are you mentioning ? We do have use cases where we have pure .a files. libsystemInfo.a being one of them, as i confirmed from our teams. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541566885
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:20:22 GMT, Suchismith Roy wrote:
>>> I think we both mean that the if (name.contains("(")) block should get
>>> removed.
>>
>> Because of the VM support, we can remove `mapAlternativeName` completely.
>
> Oh ok.Yes i have removed that now. You mean ,load library wont support it,
> but load will be able to support it since the loadLibraryIfPresent is
> returned false now.
>
> Now the loadLibrary can only handle .so to .a mapping due to
> mapAlternativeName
> Because of the VM support, we can remove `mapAlternativeName` completely.
Does VM provide support for mapping .so to .a files ? We still have cases where
the entire .a file is shared and don't need to mention the member.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541544958
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:27:43 GMT, Suchismith Roy wrote: >> Oh ok.Yes i have removed that now. You mean ,load library wont support it, >> but load will be able to support it since the loadLibraryIfPresent is >> returned false now. >> >> Now the loadLibrary can only handle .so to .a mapping due to >> mapAlternativeName > >> Because of the VM support, we can remove `mapAlternativeName` completely. > > Does VM provide support for mapping .so to .a files ? We still have cases > where the entire .a file is shared and don't need to mention the member. libsystemInfo.a is one use case ,i got after discussion with our teams, which actually raised this issue in J9. So there are cases where pure .a files exist. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541548250
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 17:19:31 GMT, Mandy Chung wrote:
>>> We are not supporting that. Are you referring to the comment in the code ?
>>> Yeah it should be resconstruction of libname(member_name).so , which is the
>>> first filename the classLoader constructs.
>>
>> Note that `System.mapLibraryName` and `mapAlternativeName` are called for
>> `System.loadLibrary` (i.e. prepending `lib` and appending `.so`).
>> "libname(member_name)" is not a valid name and no reason for
>> `System.loadLibrary` to support it.
>
>> I think we both mean that the if (name.contains("(")) block should get
>> removed.
>
> Because of the VM support, we can remove `mapAlternativeName` completely.
Oh ok.Yes i have removed that now. You mean ,load library wont support it, but
load will be able to support it since the loadLibraryIfPresent is returned
false now.
Now the loadLibrary can only handle .so to .a mapping due to mapAlternativeName
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541534243
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v6]
> 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 with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - remove member check - update comment - coding style - set false - restore fil - remove member check code - trraling spaces - trailing spaces - remove space - remove debug print lines - ... and 6 more: https://git.openjdk.org/jdk/compare/d0a26503...4c068e78 - Changes: https://git.openjdk.org/jdk/pull/17945/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17945=05 Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Wed, 27 Mar 2024 16:44:34 GMT, Mandy Chung wrote: > > So we should keep the mapAlternativeName for atleast .so to .a > > mapping(without any members mentioned). > > "libname.so(member_name)" is not a valid library name. No reason why > `System.load` has to support it. We are not supporting that. Are you referring to the comment in the code ? Yeah it should be resconstruction of libname(member_name).so , which is the first filename the classLoader constructs. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1541502377
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Tue, 26 Mar 2024 21:11:09 GMT, Mandy Chung wrote:
>> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:
>>
>>> 66: int dotIndex = name.lastIndexOf('.');
>>> 67: String memberName =
>>> name.substring(openBracketIndex,dotIndex);
>>> 68: //Reconstruct .so() as
>>> .a()
>>
>> Do we really need to support libname.so(member)? Isn't it always
>> libname.a(member)?
>
> I think `mapAlternativeName` isn't needed at all. If
> `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")`
> should be passed to dlopen directly. @suchismith1993 can verify it.
@mlchung The first name constructed by Classloader is always lib.so. So
we need a way to map it to lib.a . Else it will search for .so and fail.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540650937
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Tue, 26 Mar 2024 21:11:09 GMT, Mandy Chung wrote:
>> src/java.base/aix/classes/jdk/internal/loader/ClassLoaderHelper.java line 68:
>>
>>> 66: int dotIndex = name.lastIndexOf('.');
>>> 67: String memberName =
>>> name.substring(openBracketIndex,dotIndex);
>>> 68: //Reconstruct .so() as
>>> .a()
>>
>> Do we really need to support libname.so(member)? Isn't it always
>> libname.a(member)?
>
> I think `mapAlternativeName` isn't needed at all. If
> `loadLibraryOnlyIfPresent` returns false, `System.load("libname.a(member)")`
> should be passed to dlopen directly. @suchismith1993 can verify it.
@mlchung Correct. But, if .so file is given and it is not present , it will
throw exception. So we should keep the mapAlternativeName for atleast .so to .a
mapping(without any members mentioned).
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1540621304
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Mon, 25 Mar 2024 20:02:16 GMT, Mandy Chung wrote: > dcstartup fails because it fails to load an agent library specified via > `-agentlib:am_ibm_16` that was fixed by JDK-8320005. I assume that's what you > referred to "J9 had for a long time". This does not use > `System::loadLibrary`. It's unclear if any JNI native library is changed to > load from an archive object. Any customer reporting this issue? So when this was reported in J9, the fix was made at the classloader level. Thats when i replicated this change to OpenJDK. But on further debug i saw that in this case, directly the hotspot code was called and the classloader was not in picture. I need to confirm about customer issue again. I will do that in a few days. But is there any particular reason why we don't support loading shared archives via loadLibrary() ? It can be an insurance against future issues too. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2019965401
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
On Mon, 25 Mar 2024 18:43:33 GMT, Mandy Chung wrote:
> Do you expect if developers start to package shared objects in the format of
> archive objects? If so, it would be reasonable to support #1 for
> compatibility.
Yes. I agree. We should keep this compatibility for entire flow from
classloader to the hotspot code. And it has been in J9 for long time for the
exact same reason, which actually brought out the issue for dcstartup in
OpenJDK.
> For #2, `System::loadLibrary("foo(libfoo.so.1)"`,
> `System::load("/usr/lib/libfoo.so((libfoo.so.1)")` and
> `System::load("/usr/lib/libfoo.a((libfoo.so.1)")` are never supported. I
> think applications should use `SymbolLookup::libraryLookup` instead on Java
> 22 and later. I don't use `libclang` as the example here because that's
> related to jextract and has nothing to do with `System::load` as Maurizio
> said.
I just feel keeping load functionality is still applicable, which does not
expect a deterministic mapping (or does it ? ). if loadLibrary expects this to
be deterministic, then i agree, we should drop that.
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2018690683
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2018693188
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v5]
> 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 four additional commits since the last revision: - coding style - set false - restore fil - remove member check code - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/d361656c..212a8cf9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=04 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=03-04 Stats: 16 lines in 2 files changed: 1 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Sat, 23 Mar 2024 00:46:45 GMT, Maurizio Cimadamore wrote: > I'd like to uplevel the discussion a bit. This PR started off to tweak the > way in which `System::load` worked in AIX. We then discussed a bunch of > options, talked about `Symbol::libraryLookup` and verified that this lookup > allows to load libraries as expected in AIX. There's some jextract issues > which need to be worked out, but that's outside the scope of this PR. > > That said, is there anything that we feel could be improved in terms of > library loading support with `System::load` ? My conclusion was that, given > that in this case we needed a fully versioned archive member, it is hard to > implement and/or to expose as a simple `mapLibraryName` add-on. Is that > correct? > > If you feel that there's not much that `System::load` can do for these cases, > then I'd suggest we close this PR, and perhaps move the discussion about > jextract either on `jextract-dev` or on `panama-dev`. Thanks! I Feel it is good to at least keep the option for Java developers to use system.load for member objects. Also , the original intention of the PR was to allow .so to .a mapping if .so is not there. This fix had gone into J9 and I think it would be good to keep this support in OpenJDK too. In summary, the functionality to parse members can be kept limited to System.load and the deterministic .so to .a mapping as part of System.loadLibrary(). - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016475083
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Thu, 21 Mar 2024 22:04:28 GMT, Maurizio Cimadamore
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
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Thu, 21 Mar 2024 22:23:02 GMT, Maurizio Cimadamore wrote: > For this reason, the only thing that would make sense for `loadLibrary` to > support is `clang` which will be expanded (by `mapLibraryName`) to > `clang(libclang.so)`. But, even assuming this works: wouldn't we still have > an issue? As far as I understand (and given the code in this patch), we don't > really know (before calling `dlopen`) whether the suffix is needed or not: > whether it's an archive with an `.so` inside, or whether it's a plain `.so`. > So how can the behavior of `mapLibraryName` be deterministic? The behaviour is deterministic when we have a case where, a .so file maps to .a file without specifying any members. This was the original intention for mapAlternateName so that we can use loadLibrary to load shared objects with .so format, and on failure we fallback and check if .a exists. But to mention the member object, it looks to me that we must specify the full name and there is no direct mapping. So then we restrict that to only System.load and not System.loadLibrary ? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014770717
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Thu, 21 Mar 2024 22:23:02 GMT, Maurizio Cimadamore wrote: > > (I'm pessimistic) > > To summarize: I think that allowing version-specific names (even if > surrounded by parenthesis) in `System::loadLibrary` would be very odd. After > all, `System::loadLibrary` doesn't support versioned names, even on other > systems (and adding support for versioned library names across different > platforms is a much bigger effort). > > For this reason, the only thing that would make sense for `loadLibrary` to > support is `clang` which will be expanded (by `mapLibraryName`) to > `clang(libclang.so)`. But, even assuming this works: wouldn't we still have > an issue? As far as I understand (and given the code in this patch), we don't > really know (before calling `dlopen`) whether the suffix is needed or not: > whether it's an archive with an `.so` inside, or whether it's a plain `.so`. > So how can the behavior of `mapLibraryName` be deterministic? yes, i think the member needs to be specified in full. AIX archives can be both static and shared, so to mention the shared object member, we need to put the braces. But we also have cases, where a .so file when it doesn't exists will map deterministically to .a file , in which we use the loadlibrary. Specifying member objects is in addition to it. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014741652
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Thu, 21 Mar 2024 17:06:23 GMT, Jaikiran Pai wrote: >>> 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). >> >> I'll let Mandy and others more knowledgable of this area to correct me. From >> what I know, there was a change done a few releases back in the JDK >> (https://bugs.openjdk.org/browse/JDK-8275703) which accomodated macos >> platform where it too doesn't actually have the file on the filesystem in >> recent versions of macos. That change allowed platform specific code to >> dictate whether the file existence check needs to be done here in this >> loadLibrary code. That's done through the call to >> `jdk.internal.loader.ClassLoaderHelper.loadLibraryOnlyIfPresent()`. For >> macos, that implementation of that method resides in macos specific class >> here >> https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java#L41. >> For AIX too then, perhaps you could add an implementation which returns >> `false` (either always or in specific cases) and experiment with that to see >> if that's enough? > >> For AIX too then, perhaps you could add an implementation which returns >> false (either always or in specific cases) and experiment with that to see >> if that's enough? > > I see that you actually have a ClassLoaderHelper in this PR for AIX, but that > implementation in `loadLibraryOnlyIfPresent()` is currently returning `true` > and thus enforcing the file existence check. Was it intentional to have it to > `true`? Given the context of this change, shouldn't it be returning `false`? Correct. Had kept it as true, as it was in J9. but changing it to false works. So that would mean we are letting the java Runtime to handle paths that don't exist ? - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1535320320
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Thu, 21 Mar 2024 20:29:16 GMT, Mandy Chung wrote: > As @jaikiran suggests, `loadLibraryOnlyIfPresent()` should return false for > AIX as the file does not exist. The library implementation may need to adjust > as the current implementation uses a file path name. Had kept it as true, as it was in J9. but changing it to false works. So that would mean we are letting the java Runtime to handle paths that don't exist ? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014728820
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Thu, 21 Mar 2024 15:51:59 GMT, Suchismith Roy 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.(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.(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.(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.(constants$17.java:46)](mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.constants$17.%3
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Tue, 19 Mar 2024 10:01:31 GMT, Suchismith Roy wrote: >>> > In AIX, we have an usecase where shared libraries have certain member >>> > objects to be referred to. E.g libclang.a(shr_64.o) . >>> >>> Would you happen to know any official documentation which explains that AIX >>> syntax? >>> >> >> https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command >> Text : >> >> **autoload: path/file(member) | Automatically load the archive member. >> -- | --** >> Autoload is a flag used to load archive members. The format of the path is >> mentioned. > >> 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.(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.(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 welibclang.a and 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) - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1534186639
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Tue, 19 Mar 2024 09:58:04 GMT, Suchismith Roy wrote: >>> In AIX, we have an usecase where shared libraries have certain member >>> objects to be referred to. E.g libclang.a(shr_64.o) . >> >> Would you happen to know any official documentation which explains that AIX >> syntax? >> >>> When we provide the path to loadLibrary() >> >> Do you mean some application code is calling the `System.loadLibrary()` >> method with such values? > >> > In AIX, we have an usecase where shared libraries have certain member >> > objects to be referred to. E.g libclang.a(shr_64.o) . >> >> Would you happen to know any official documentation which explains that AIX >> syntax? >> > > https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command > Text : > > **autoload: path/file(member) | Automatically load the archive member. > -- | --** > Autoload is a flag used to load archive members. The format of the path is > mentioned. > 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.(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.(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) - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530059834
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Mon, 18 Mar 2024 17:40:04 GMT, Jaikiran Pai wrote: > > In AIX, we have an usecase where shared libraries have certain member > > objects to be referred to. E.g libclang.a(shr_64.o) . > > Would you happen to know any official documentation which explains that AIX > syntax? > https://www.ibm.com/docs/en/aix/7.2?topic=l-ld-command Text : **autoload: path/file(member) | Automatically load the archive member. -- | --** Autoload is a flag used to load archive members. The format of the path is mentioned. - PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1530054525
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
> 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 - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/c20e2862..d361656c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=03 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v3]
> 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: trailing spaces - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/cd219603..c20e2862 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=02 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
On Mon, 18 Mar 2024 17:24:05 GMT, Jaikiran Pai wrote:
>> Suchismith Roy has updated the pull request incrementally with seven
>> additional commits since the last revision:
>>
>> - remove space
>> - remove debug print lines
>> - remove debug print lines
>> - remove debug lines
>> - variable name check
>> - code cleanup
>> - made changes to file loading procedure
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 130:
>
>> 128: //Remove member name in brackets from
>> file pathname, as such pathnames do not exist.
>> 129: //Original pathname with bracket is
>> returned,which is handled by dlopen() in AIX.
>> 130: if (file.getName().contains("(")){
>
> Hello @suchismith1993, can you provide us some context on what this check is
> about? Is some code application code calling `System.load("foo(bar");` and
> this code in then trying to remove that `(`?
>
> Adding this code here wouldn't be right. Plus, I see that in this new `if`
> block, the code then goes and renames the underlying `File` to a new name,
> which too isn't right.
>
> Knowing the context of why this is needed would help us understand if
> anything needs to change here.
In AIX, we have an usecase where shared libraries have certain member objects
to be referred to.
E.g libclang.a(shr_64.o) .
When we provide the path to loadLibrary(), it searches if the file exists as
absolute path .i.e libclang.a(shr_64.o), but such a path doesn't exist, only
dlopen() would be able to recognise the member object mentioned in the path and
able to load it.
So before the code transitions to native code where dlopen() happens, the
member object is being removed from the filename,so that the right path is
referred(libclang.a) , and then the original path name with member name is
passed on to the dlopen()
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1528982168
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v2]
> 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 seven additional commits since the last revision: - remove space - remove debug print lines - remove debug print lines - remove debug lines - variable name check - code cleanup - made changes to file loading procedure - Changes: - all: https://git.openjdk.org/jdk/pull/17945/files - new: https://git.openjdk.org/jdk/pull/17945/files/9ad12257..cd219603 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17945=01 - incr: https://webrevs.openjdk.org/?repo=jdk=17945=00-01 Stats: 34 lines in 2 files changed: 32 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader
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) - Commit messages: - Add support for AIX dynamic libraries in Class Loader Changes: https://git.openjdk.org/jdk/pull/17945/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17945=00 Issue: https://bugs.openjdk.org/browse/JDK-8319516 Stats: 81 lines in 1 file changed: 81 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17945/head:pull/17945 PR: https://git.openjdk.org/jdk/pull/17945
