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 Mon, 18 Mar 2024 17:43:45 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: > > trraling spaces Thanks! Agreed. jextract is crashing in libclang.a::llvm::MemoryBuffer::getMemBufferRef() in a new llvm thread (could be related to the signal handler issue). That seems to be unrelated to this issue and shouldn't be discussed here. It would be nice if loading such libraries could be made easier for Java developers. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016470368
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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: > > trraling spaces 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! - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016237758
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Fri, 22 Mar 2024 19:56:30 GMT, Martin Doerr wrote: > The symbols get found and the JVM can really call into the > `libclang.a(libclang.so.16)`. Impressive! (That doesn't mean that jextract is > working. clang crashes the way we are calling it. Maybe because of a thread > stack size or other memory management problem.) So, there is basically a > valid solution for loading such libraries. Only not very smooth for Java > programmers. Note that the jextract code itself depends on bindings generated via jextract (!!). So, I wonder if there might be some incompatibility in the generated layouts/descriptors, which is then causing the crash.The generated bindings are here: https://github.com/openjdk/jextract/tree/master/src/main/java/org/openjdk/jextract/clang/libclang These bindings are effectively shared across Linux/x64, Macos/x64, Macos/arm64 and Win/x64 - that is, all the layouts in there are valid and portable on these platforms (except for `C_LONG` on Windows, but libclang is quite disciplined and only uses `long long`). I'd try few steps: 1. check that your libclang.so is not broken, by calling `clang_version` in a C program and making sure that works w/o crashing 2. then try to do the same (w/o jextract) using FFM, from Java, and see if that still works If even (1) fails, you might just have a bad libclang, or one that is not for your system (not all the binary downloads in the LLVM website worked on my machine, even if they were supposedly compatible). If (1) succeds, but (2) fails, that would indicate some general issue with libclang and the JVM. There is an issue that we currently have to workaround, where libclang tries to install its own signal handlers, which mess up the JVM's signal handler to deal with NPEs (and that causes a random JVM crash). This is documented here: https://reviews.llvm.org/D23662 We try to call "setenv" to disable that logic, but that might fail or not be supported on your platform, so worth checking that. Finally, if (1) and (2) both succeed, but you get spurious JVM crashes with jextract, then I'd start looking at jextract's bindings (the ones in the folder above), pick a struct (e.g. CXCursor, or CXString) and then inspect the layout and make sure that corresponds to what the layout should be in AIX - it is possible that the AIX compiler inserts some extra padding, and then passing structs with the wrong size in and out of libclang would explain the issues. Hope this helps! - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2016231211
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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:
>
> trraling spaces
Ah, right. Thanks! I should use that `SymbolLookup`:
diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
index 14eba30..4f92f43 100644
--- a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
+++ b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
@@ -27,11 +27,13 @@
package org.openjdk.jextract.clang.libclang;
+import java.io.File;
import java.lang.invoke.*;
import java.lang.foreign.*;
import java.nio.ByteOrder;
import java.util.*;
import java.util.function.*;
+import java.util.StringTokenizer;
import java.util.stream.*;
import static java.lang.foreign.ValueLayout.*;
@@ -100,14 +102,27 @@ public class Index_h {
throw new IllegalArgumentException("Invalid type for ABI: " +
c.getTypeName());
}
+static SymbolLookup SYMBOL_LOOKUP;
+
static {
-String libName = System.getProperty("os.name").startsWith("Windows") ?
"libclang" : "clang";
-System.loadLibrary(libName);
+String osName = System.getProperty("os.name");
+String libName = "";
+if (osName.startsWith("AIX")) {
+String libPath = System.getProperty("java.library.path");
+StringTokenizer parser = new StringTokenizer(libPath, ":");
+while (parser.hasMoreTokens()) {
+libName = parser.nextToken() + "/libclang.a";
+File f = new File(libName);
+if (f.exists() && !f.isDirectory()) break;
+}
+SYMBOL_LOOKUP = SymbolLookup.libraryLookup(libName +
"(libclang.so.16)", Arena.global());
+} else {
+libName = osName.startsWith("Windows") ? "libclang" : "clang";
+System.loadLibrary(libName);
+SYMBOL_LOOKUP =
SymbolLookup.loaderLookup().or(Linker.nativeLinker().defaultLookup());
+}
}
-static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup()
-.or(Linker.nativeLinker().defaultLookup());
-
public static final ValueLayout.OfBoolean C_BOOL =
ValueLayout.JAVA_BOOLEAN;
public static final ValueLayout.OfByte C_CHAR = ValueLayout.JAVA_BYTE;
public static final ValueLayout.OfShort C_SHORT = ValueLayout.JAVA_SHORT;
The symbols get found and the JVM can really call into the
`libclang.a(libclang.so.16)`. Impressive! (That doesn't mean that jextract is
working. clang crashes the way we are calling it. Maybe because of a thread
stack size or other memory management problem.) So, there is basically a valid
solution for loading such libraries. Only not very smooth for Java programmers.
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015811096
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Fri, 22 Mar 2024 16:53:58 GMT, Martin Doerr wrote:
> In case of jextract (jdk22 branch), we would then need something like the
> following if we want AIX to behave like the other platforms?
>
> ```
> diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> index 14eba30..c069c3b 100644
> --- a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> +++ b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
> @@ -27,11 +27,13 @@
>
> package org.openjdk.jextract.clang.libclang;
>
> +import java.io.File;
> import java.lang.invoke.*;
> import java.lang.foreign.*;
> import java.nio.ByteOrder;
> import java.util.*;
> import java.util.function.*;
> +import java.util.StringTokenizer;
> import java.util.stream.*;
>
> import static java.lang.foreign.ValueLayout.*;
> @@ -101,8 +103,21 @@ public class Index_h {
> }
>
> static {
> -String libName = System.getProperty("os.name").startsWith("Windows")
> ? "libclang" : "clang";
> -System.loadLibrary(libName);
> +String osName = System.getProperty("os.name");
> +String libName = "";
> +if (osName.startsWith("AIX")) {
> +String libPath = System.getProperty("java.library.path");
> +StringTokenizer parser = new StringTokenizer(libPath, ":");
> +while (parser.hasMoreTokens()) {
> +libName = parser.nextToken() + "/libclang.a";
> +File f = new File(libName);
> +if (f.exists() && !f.isDirectory()) break;
> +}
> +SymbolLookup.libraryLookup(libName + "(libclang.so.16)",
> Arena.global());
> +} else {
> +libName = osName.startsWith("Windows") ? "libclang" : "clang";
> +System.loadLibrary(libName);
> +}
> }
>
> static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup()
> ```
>
> If I try this, I get "UnsatisfiedLinkError: unresolved symbol:
> clang_createIndex". So, seems like the lib gets found, but symbols not
> loaded. Seems like there are more changes needed.
Something like that seems good. When you call "find" on that lookup, it should
just forward to dlsym... I suggest you try first to simply use the lookup in a
standalone file (w/o jextract) and try to lookup a symbol in clang (e.g.
`clang_getClangVersion`), and see what happens.
If that doesn't work (likely), I'd suggest to write the equivalent C program
with dlopen/dlsym, and make sure that works, and also note which DLOPEN/DLSYM
parameters are used (maybe those are different from the ones used by the JDK?).
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015773691
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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:
>
> trraling spaces
In case of jextract (jdk22 branch), we would then need something like the
following if we want AIX to behave like the other platforms?
diff --git a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
index 14eba30..c069c3b 100644
--- a/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
+++ b/src/main/java/org/openjdk/jextract/clang/libclang/Index_h.java
@@ -27,11 +27,13 @@
package org.openjdk.jextract.clang.libclang;
+import java.io.File;
import java.lang.invoke.*;
import java.lang.foreign.*;
import java.nio.ByteOrder;
import java.util.*;
import java.util.function.*;
+import java.util.StringTokenizer;
import java.util.stream.*;
import static java.lang.foreign.ValueLayout.*;
@@ -101,8 +103,21 @@ public class Index_h {
}
static {
-String libName = System.getProperty("os.name").startsWith("Windows") ?
"libclang" : "clang";
-System.loadLibrary(libName);
+String osName = System.getProperty("os.name");
+String libName = "";
+if (osName.startsWith("AIX")) {
+String libPath = System.getProperty("java.library.path");
+StringTokenizer parser = new StringTokenizer(libPath, ":");
+while (parser.hasMoreTokens()) {
+libName = parser.nextToken() + "/libclang.a";
+File f = new File(libName);
+if (f.exists() && !f.isDirectory()) break;
+}
+SymbolLookup.libraryLookup(libName + "(libclang.so.16)",
Arena.global());
+} else {
+libName = osName.startsWith("Windows") ? "libclang" : "clang";
+System.loadLibrary(libName);
+}
}
static final SymbolLookup SYMBOL_LOOKUP = SymbolLookup.loaderLookup()
If I try this, I get "UnsatisfiedLinkError: unresolved symbol:
clang_createIndex". So, seems like the lib gets found, but symbols not loaded.
Seems like there are more changes needed.
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015506765
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Fri, 22 Mar 2024 14:53:17 GMT, Martin Doerr wrote: > Only the Java developer can select the right member. Right, and I think this problem is isomporphic to the problem we have in Linux distros of selecting between libclang.so.1 and libclang.so.2. `System::loadLibrary` cannot do it. So, I think it would feel odd if, say AIX was able to load precise version of a library using the member syntax, but in all other platforms that would not be possible. For better or worse, the story for now is: if you want version, use `System::load`. In this case, the problem might be that `System::load` doesn't work out of the box, as the path doesn't really exist. But this doesn't seem different to loading non-existing framework paths in MacOS - e.g. it is a special case that can be added for AIX (when using `System::load`). All that said, if one is doing `System::load/loadLibrary` just because they want to use FFM and `Linker`, a better way to do that is to just use `SymbolLookup::libraryLookup` directly, which gives you direct access to whatever string `dlopen` accepts in your system. Now, I realize that `jextract` is currently using `SymbolLookup::loaderLookup`, but I believe we can change that, which in turn will make adding support for AIX a bit easier. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015299960
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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: > > trraling spaces `dlopen` really expects `libclang.a(libclang.so.16)`. I don't think this can currently be passed by any of the functions `System.loadLibrary`, `System.load` or `SymbolLookup.libraryLookup`. The `.16` suffix is only for clang 16. Clang 15 uses `.15`. Note that AIX uses archive members quite often. E.g. `libc.a(shr_64.o)`, `libpthreads.a(shr_xpg5_64.o)`, `libz.a(libz.so.1)`, ... Only the Java developer can select the right member. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2015274997
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 [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 [v4]
On Thu, 21 Mar 2024 22:04:28 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? - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013954504
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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:
>
> trraling spaces
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)
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013909303
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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: > > trraling spaces `os::dll_load` already handles loading from .a on AIX when attempting loading .so (see JDK-8320005). For example, if loading `libclang.so` fails, it attempts to load from `libclang.a`.This issue is essentially revisiting the fix for JDK-8320005 and needs to understand the right mapping. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013811988
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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:
>
> trraling spaces
JDK-8313616 added the support of loading library members on AIX in os::dll_load
in JDK 22. On AIX, is a shared object a member object loaded from
`libname.a(libname.so)`? If so, changing `mapLibraryName` implementation
seems to be a proper fix. If you want to load a specific version, it should
call `loadLibrary("libclang.a(libclang.so.16)")` instead.
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.
-
PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013669909
Re: RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
On Mon, 18 Mar 2024 17:43:45 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: > > trraling spaces I think ideally the member suffix should be added by `System.mapLibraryName` since that takes care of mapping the platform agnostic library name to a platform specific string that identifies a library. Is it possible to infer the member name from the library name? (e.g. from `clang` infer `clang(libclang.so.16)`). FWIW, there exists an API that is a more direct proxy for dlopen, which is `SymbolLookup.libaryLookup`. - PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2013435496
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
