changeEvent is not implemented (https://github.com/bytedeco/javacpp-presets/blob/d8d0b470c185fcf22359192452bc0ad85829d84d/qt/src/main/java/org/bytedeco/qt/presets/Qt5Widgets.java#L187) if this is what skip() means
java -jar javacpp.jar Test.java -header, the command runs a Info: g++ -I/path/to/include ... That include path is correct. However when I run it using the graalvm jvm, it somehow ends up with the wrong -I path
which java
/home/crispin/graalvm-ce-java11-20.1.0/bin/java
which javac
/home/crispin/graalvm-ce-java11-20.1.0/bin/javac
java -jar ~/.m2/repository/org/bytedeco/javacpp/1.5.3/javacpp-1.5.3.jar Mullion.java -header
...
Info: g++ -I/home/crispin/graalvm-ce-java8-20.2.0-dev/include -I/home/crispin/graalvm-ce-java8-20.2.0-dev/include/linux ....
@Cast("uint16_t*") works, but @Cast("uint16_t") would not
@Cast({"signed char*", "std::vector<char>"}) @StdVector byte[] with CharVector
test_cc
BEGIN /tmp/ffconf.xTy4tl3y/test.c
1 int main(void){ return 0; }
END /tmp/ffconf.xTy4tl3y/test.c
gcc -m64 -I../include/ -c -o /tmp/ffconf.xTy4tl3y/test.o /tmp/ffconf.xTy4tl3y/test.c
gcc -m64 -L../lib/ -Wl,-rpath,\$$ORIGIN/ -o /tmp/ffconf.xTy4tl3y/test /tmp/ffconf.xTy4tl3y/test.o -lstdc++ -lpthread -ldl -lz -lm -lva-drm -lva-x11 -lva
/usr/bin/ld: cannot find -lva-drm
/usr/bin/ld: cannot find -lva-x11
/usr/bin/ld: cannot find -lva
collect2: error: ld returned 1 exit status
C compiler test failed.
Hi @saudet , i am trying to use javacpp with my roboVM project.
Generating the gluecode (jnijavacpp.m, jniNativeLibrary.mm) and compiling all native code to a static library worked fine.
But when trying to create objects from the generated java code the app crashes at runtime without stacktrace. Only following warnings occur:
Warning: Could not load Loader: java.lang.UnsatisfiedLinkError: Couldn't load jnijavacpp from loader java.lang.PathClassLoader[<Main.app/lib/multiple jars>]: findLibrary returned null
Warning: Could not load Pointer: java.lang.UnsatisfiedLinkError: Couldn't load jnijavacpp from loader java.lang.PathClassLoader[<Main.app/lib/multiple jars>]: findLibrary returned null
com.erikgrodemo.demo.app: 99078
Process finished with exit code 0
Since the libraries are statically linked and dont need to be loaded at runtime i removed all “static { Loader.load(); }” from the generated code. Is this correct?
I thought that jnijavacpp should be available since it is statically linked. Do you have any idea what i could be missing?
The approach of loading the library mentioned in the README for RoboVM links the library statically.
Static libraries are possible in roboVM since java code gets compiled to machinecode. The static library is linked at compile time with the executable.
So my understanding of System.load is that it searches the library path and eventually calls jni_onload which is used to initializing javacpp.
So System.load always crashes since there is no library on the library path.
I found out that the native functions actually get called, but it crashes eventually because jni_onload and thus the initialization was never executed.
Ok after some digging around, I found out I misunderstood system.load(). Even with static libraries it should call jni_onload_lib. But in a minimal demo project with roboVM i found out, that it seems like roboVM does not support the official jni standard, which states:
“If a library L is statically linked, then upon the first invocation of System.loadLibrary("L") or equivalent API, a JNI_OnLoad_L function will be invoked with the same arguments and expected return value as specified for the JNI_OnLoad function.”
You already mentioned it in your changelog from 2014: https://github.com/bytedeco/javacpp/blob/57574c2dafbc846b5cec2a968894424246a9e882/CHANGELOG.md#january-6-2014-version-07
So if onload is not called i guess initializing manually the native code might be an option.
@Platform(resource=...)will be bundled that way.
Loader.cacheResource() to have it extracted and cached.
