RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]
Martin Doerr
mdoerr at openjdk.org
Fri Mar 22 19:59:22 UTC 2024
On Mon, 18 Mar 2024 17:43:45 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 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
More information about the core-libs-dev
mailing list