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

Mandy Chung mchung at openjdk.org
Mon Mar 25 18:46:30 UTC 2024


On Mon, 25 Mar 2024 09:46:50 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - coding style
>  - set false
>  - restore fil
>  -  remove member check code

JDK-8313616 changes HotSpot VM to support loading member objects from .a on AIX dlopen.   That RFE was a reasonable change as AIX JDK may load native libraries from an archive file of a named member object e.g. `/usr/lib/libperfstat.a(shr_64.o)`

JDK-8320005 was the first attempt to fix `dcstartup` and second attempt by this issue in JDK 23.   This changes HotSpot VM to load from an alternate path if `os::dll_load(lib_path)`, which in turn calls dlopen` on AIX,  fails to load `lib_path` with `.so` suffix, it tries to load with an alternatve path by replacing `.so` with `.a`.

This issue (JDK-8319516) attempts to change the library implementation as follows:
1. `System::loadLibrary("foo")` to call `dlopen("/usr/lib/libfoo.so")` first; if fails, `dlopen("/usr/lib/libfoo.a")`
2. `System::load("/usr/lib/libfoo.so(libfoo.so.1)"` that will call (1) `dlopen("/usr/lib/libfoo.so((libfoo.so.1)")`, if fails (2) `dlopen("/usr/lib/libfoo.a((libfoo.so.1)")`.

On AIX, loading shared objects from an archive object via `System::loadLibrary` and `System::load` never work before.

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.

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.

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

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2018669567


More information about the core-libs-dev mailing list