Can't load personal dll with jna from netbeans - java

I'm using netbeans 7.4 / jdk 1.7u51
I downloaded the jar for JNA from official site, in version 4.0.0.
I have an internally developped DLL whose interface is in plain C, which loads perfectly well with ctypes in python. This dll is compiled in release with visual 2010, whose runtime are in path.
D:\fl006\Downloads>dir D:\deploy\SpotLight\spotlight-1488\PasanBusLibrary.dll
Directory of D:\deploy\SpotLight\spotlight-1488
29.01.2014 11:13 1'690'112 PasanBusLibrary.dll
I tried to load it in java with jna:
public interface CLibrary extends Library {
(...snip...)
void pasanIpcInitializeLibrary(String xClient, String xBusName, int xTimeout);
void pasanIpcTerminateLibrary();
}
public static void main(String[] args) {
NativeLibrary.addSearchPath("PasanBusLibrary","D:\\deploy\\SpotLight\\spotlight-1488");
CLibrary Bus = (CLibrary) Native.loadLibrary("PasanBusLibrary",CLibrary.class);
(... snip ...)
This is basically an out of the book standard dll load, from a custom location.
When activating jna debug, I see the following :
run:
Looking in classpath from sun.misc.Launcher$AppClassLoader#714a8f44 for /com/sun/jna/win32-x86-64/jnidispatch.dll
Found library resource at jar:file:/D:/code/perso/TestWrapperBus/jna-4.0.0.jar!/com/sun/jna/win32-x86-64/jnidispatch.dll
Looking for library 'PasanBusLibrary'
Adding paths from jna.library.path: null
Trying D:\deploy\SpotLight\spotlight-1488\PasanBusLibrary.dll
Adding system paths: []
Trying D:\deploy\SpotLight\spotlight-1488\PasanBusLibrary.dll
Looking for lib- prefix
Trying libPasanBusLibrary.dll
Looking in classpath from sun.misc.Launcher$AppClassLoader#714a8f44 for PasanBusLibrary
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'PasanBusLibrary': Native library (win32-x86-64/PasanBusLibrary.dll) not found in resource path ([file:/D:/code/perso/TestWrapperBus/jna-4.0.0.jar, file:/D:/code/perso/TestWrapperBus/jna-platform-4.0.0.jar, file:/D:/code/perso/TestWrapperBus/build/classes/])
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:271)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:398)
at com.sun.jna.Library$Handler.<init>(Library.java:147)
at com.sun.jna.Native.loadLibrary(Native.java:412)
at com.sun.jna.Native.loadLibrary(Native.java:391)
at testwrapperbus.TestWrapperBus.main(TestWrapperBus.java:39)
It looks it looks through the location I gave and somehow discards it. I tried different folders and I got same behaviour, there is no obvious file system right issue (dll is RW from all users)
Any clue on what I'm missing, I'm kind of stuck currently...
EDIT
if I load "msvcrt" this is working nice to cll printf
my dll has some dependencies, all of them hosted in c:\windows\system32 (standard runtime, dynamically linked)

My dll is a win32 compilation while I use a win64 JDK / JRE. Of course, when dealing with pure java, we don't care but loading native library needs to match.
I tried running from command line on a 32 bits JRE7 and it worked, so I'm pretty sure that installing JDK for win32 in my netbeans or recompiling my dll in 64 bits will solve the issue.
Thanks to this answer : Trying to use DLL from Java (JNA). Unable to load library exception for having put me on the righteous path

Related

JavaNativeFoundation.framework comes without major version in Azul and Liberica JDK – how can I tell Java to use it anyway?

I am trying to use a native library on an ARM based Mac, i.e. an M1 processor. There are several JVMs available for that architecture, for example Azul or Liberica. Both come with a JavaNativeFoundation.framework dynamic library, which is necessary to use any JNI code. However, the framework does not have a Versions folder that contains the major version of the framework (like A). Instead, the library is just contained in the top level folder:
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/_CodeSignature
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/_CodeSignature/CodeResources
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/JavaNativeFoundation
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/Resources
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/Resources/Info.plist
Trying to run my program I get
[java] AquaNativeSupport: Unable to load library libvaqua.dylib: /private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib: dlopen(/private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib, 0x0001): Library not loaded: #rpath/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
[java] Referenced from: /private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib
[java] Reason: tried: '/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/server/./JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file),
'/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/server/../JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file),
'/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/bin/./JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file),
'/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/bin/../lib/JavaNativeFoundation.framework/Versions/A/Java
It looks like the output is incomplete, but anyway: You can see that java is trying to load the framework from a Versions/A/ subfolder of the framework, which does not exist anywhere.
If I create that subfolder and create a softlink to the existing binary JavaNativeFoundation in it, then the application loads the JNI code just fine.
Given that situation I have two questions:
Why are the Frameworks in both Azul/zulu and Liberica missing the Versions structure?
Is there a way to work around that problem by loading the Framework in a different way? Some "dontusemajorversion" flag?
Thank you for your help.

Is there a way to set up dependency for javacv's native part in maven, without manual installation and setting up java.library.path?

I have dependencies on org.bytedeco:opencv:4.1.2-1.5.2 that is in turn added to the project by
<groupId>org.datavec</groupId>
<artifactId>datavec-data-image</artifactId>
<version>${datavec.version}</version>
And for the needs of datavec-data-image the open-cv is loaded well and all the internal open-cv actions are executed.
Then, I'd like to do some open cv executions explicitly. I use a class from https://github.com/rostrovsky/pdf-table that does this stuff:
public class PdfTableReader {
private TableExtractor extractor;
private PdfTableSettings settings;
static {
System.loadLibrary(Core.NATIVE_LIBRARY_NAME);
}
and it fails with
Exception in thread "main" java.lang.UnsatisfiedLinkError: no opencv_java412 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at pdftable.PdfTableReader.<clinit>(PdfTableReader.java:32)
at pdftable.ExtractSyzlekFromPdf.main(ExtractSyzlekFromPdf.java:12)
What I should to do to make this explicit javacv part to work with datavec image code without doing the double explicit open-cv installation to some location on my pc and setting up the java.library.path explicitly? At least the datavec image code obtains it somehow without this explicit set up.
I also tried to follow up this answer: https://stackoverflow.com/a/57515132/1759063 but with no success (if I understand right, they use the dependency that ships native libs in a cross-platform way, i.e. ships all platform binaries and the needed one is used on the right platform). I suppose there should be a way to make java.library.path to be dynamically updated if the open-cv native binaries packed to the maven dependencies are attached to the project. But how?
If DL4J guys can explain how to use the javacv part there correctly, that would be perfect.
The Java API of OpenCV found in the org.opencv package doesn't come with a loader, so the libraries need to be loaded by something else externally. In the case of the JavaCPP Presets for OpenCV, the libraries and wrappers are all bundled in JAR files and we can call Loader.load(opencv_java.class) to load everything as documented here:
https://github.com/bytedeco/javacpp-presets/tree/master/opencv#documentation
JavaCV, Deeplearning4j, and DataVec do not use that Java API of OpenCV, they use the API found in the org.bytedeco.opencv package, which loads everything automatically, so they do not need to call anything.

JNI "The specified procedure could not be found" when dependent library is linked

Following is the basic working structure:
MainProxy.dll ==> JNIClient.java
Using JNI, I have successfully loaded the MainProxy.dll and able to call the native functions. Following is the required structure:
Main.dll ==> MainProxy.dll ==> JNIClient.java
But when MainProxy.dll compiled and linked with another DLL Main.dll the System.loadLibrary("MainProxy"); call crashed with an exception
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: MainProxy.dll: The specified procedure could not be found
However, the MainProxy.dll is successfully compiled and linked against Main.lib and both DLLs are placed to gather with java.
Any idea what causes this issue and how it can be resolved?
Above is the snap from dependencywalker. The ISPVPLPR.dll is the Main.dll and LPRPROXY.DLL is the MainProxy.dll. And the linking between these two looks fine. The CreateNativeClass is exported along with other functions from ISPVPLPR.dll while only CreateNativeClass is imported in LPRPROXY.dll.
Above snap shows that exported native function from LPRProxy.dll
Finally, it turns out that OpenCV pre-compiled libraries was the issue. The ISPVPLPR.DLL was utilizing OpenCV and the copied DLLs were the default that came with setup and were compiled for WinXP Prof 64bit or Win2003 64bit. Since Opencv_Core241.dll requires RtlLookupFunctionEntry and RtlVirtualUnwind functions from Kernel32.dll and these functions were only provided for WinXP and Win2003 Kernel32.dll versions (MSDN Reference).
The solution was simple to recompile the OpenCV2.4.1 for Win7 and with GOD blessings it worked.
I recommend you to use Dependency Walker from microsoft. Use this utility to really check if MainProxy.dll is correctly linked with Main.dll.
If Dependency Walker shows you a problem, tell us how do you compiled and linked MainProxy.dll.
When Dependency Walker shows you no problem, you won't have anymore an java.lang.UnsatisfiedLinkError

Mac + jni + java

A little background:
I have a java application that needs to talk to a third party hardware on mac. They have given me the sdk but it is not in Java. So I am trying to make jnilib that will act as a bridge between my java application and the SDK.
The issue:
I have made a small sample jnilib that talks to the SDK but when I try to use it in my java program I get the following error
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/john.doe/Desktop/eclipse/workspace/Lesson13_Jni_Smart7/bin/libSmartTest7.jnilib: Library not loaded: build/Release/SMARTResponseSDK.framework/Versions/A/SMARTResponseSDK Referenced from: /Users/john.doe/Desktop/eclipse/workspace/Lesson13_Jni_Smart7/bin/libSmartTest7.jnilib
Reason: image not found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1827)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1742)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1045)
at com.learning.lesson13.JniSmart7.<clinit>(JniSmart7.java:6)
From the error it looks like my libSmartTest7.jnilib is looking for the library SMARTResponseSDK.
What I have tried
I know where the library SMARTResponseSDK is on my Mac. I tried copying it over to my working folder in eclipse but I still get the error. I have tried using the -DJava.library.path but I still get the error.
Any ideas on what the best possible approach would be.
Once you are inside JNI code, it no longer matters what java.library.path points at.
Once you are inside JNI code, all you can do is to make sure library is visible to your code via LD_LIBRARY_PATH/DYLD_LIBRARY_PATH, or you can dynamically load your library file from any location you like.
So, for you, I suggest to take a look here:
dynamic loading of library in JNI - http://jnicookbook.owsiak.org/recipe-No-018/
Calling code from shared library (adapter pattern) - http://jnicookbook.owsiak.org/recipe-No-023/
You can also benefit from compilation flags while building your JNI library and use rpath.

SWIG c++ Java DLL Windows

my problem: creating a java wrapper for a c++ DLL.
I know, there are many articles about this issue but so far no solution for me.
Then problem:
I have java 1.6 up 29 32-bit installed on my windows 7, 64 bit, at C:\java\jdk.
This path is part of path variable (open cmdline anywhere, i can always calls javac...)
I have latest swig, which successfully created python and perl wrappers for my DLL.
When i buld java/class sample with VS2008 - which completes without errors - and try to run the runme.java i get the error:
UnsatisfiedLinkError
-> Native code library failed to load. See the chapter on Dynamic Linking Problems in the SWIG Java documentation for help
the DLL is very simple. Statically linked to runtime libs (/MT). No dependecies but still
getting this error.
Please note: the swig sample does not work. Java installed. Also the tcl sample does not work.
tcl 8.4 installed (similar error).
Any help is appreciated.
Thank you
Your class has been compiled successfully, and the native library has been compiled successfully. The issue is that the Java code needs to load, at runtime, the shared object which you generated with Visual Studio.
Try passing -Djava.library.path=<directory containing your DLL> when you run the class.
From the looks of what you've described it seems like you've not loaded the DLL you compiled within Java before trying to call one of the (generated by SWIG) JNI methods.
I normally use something like:
%pragma(java) jniclasscode=%{
static {
try {
System.loadLibrary("module");
} catch (UnsatisfiedLinkError e) {
System.err.println("Native code library failed to load. \n" + e);
System.exit(1);
}
}
%}
in my SWIG interface file to cause the DLL to be loaded automatically at runtime by the Java code.
(You'll need to make sure the DLL is placed somewhere appropriate with respect to library paths on your system).

Categories

Resources