I'm using the JNA's com.sun.jna.NativeLibrary class in order to load the VLCJ native library. I'm working on an armv8(aarch x64)-based linux device. Below is my code, note that i am using the latest JNA version jna-4.5.2:
NativeLibrary.addSearchPath(RuntimeUtil.getLibVlcLibraryName(), Constants.DEPLIB_OUTPUT_DIRECTORY);
Native.loadLibrary(RuntimeUtil.getLibVlcLibraryName(), LibVlc.class);
LibXUtil.initialise();
First i was getting this error:
java.lang.UnsatisfiedLinkError: JNA native support (com/sun/jna/linux-aarch64/libjnidispatch.so) not found in resource path
After a quick search i found that i must copy the jna native lib directory from inside the jar into the jvm lib path, where the jna jar library has pre-built libraries for almost all known systems as shown in the image below:
jna-4.5.2 internal content.jpeg
After doing that, the above exception disappeared but another one came up:
java.lang.UnsatisfiedLinkError: Can't obtain static method fromNative(Method, Object) from class com.sun.jna.Native
the exception is saying that it couldn't find the method fromNative(Method, Object) in the class com.sun.jna.Native however after decompiling this class i found that the method already exists.
I'm out of ideas know, any help would be highly appreiated, thanks!.
solve by:
undo this step:
After a quick search i found that i must copy the jna native lib
directory from inside the jar into the jvm lib path...
remove all jna modules (jars) from my project
download and link the following jars into my project:
jna.jar
jna-platform.jar
linux-aarch64.jar
If the jar files: jna-5.11.0.jar and jna-platform-5.11.0.jar (or whatever version number you are using) if in you lib path (build path in Eclipse), the java command option:
-Djna.nosys=true
may solve the problem. When first started, JNA is loads its own native access library and it wasn't finding it. jna.nosys=true allows JNA to look in the jna-X.XX.X.jar file for what it needs. The error message confused my because JNA seemed to be found and loaded, but it was complaining about not finding 'fromNative'.
From JNA documentation:
Loading JNA
JNA includes a small, platform-specific shared library which enables all
native access. When the Native class is first accessed, JNA will first
attempt to load this library from the directories specified in
jna.boot.library.path. If that fails and jna.nosys=false is set, it will
fall back to loading from the system library paths. Finally it will attempt
to extract the stub library from from the JNA jar file, and load it.
The jna.boot.library.path property is mainly to support jna.jar being
included in -Xbootclasspath, where java.library.path and LD_LIBRARY_PATH are
ignored. It is also useful for designating a version of the library to use
in preference to any which may already be installed on the system.
...
I'm having trouble loading a statically compiled library from Java using System.loadLibrary("") but I can load it as a dynamically compiled library (when I build it that way) just fine. I'm using JDK 8 and my understanding is it can load static libraries via System.loadLibrary("") if you provide a JNI_OnLoad_L in the *.cpp and *.h files.
My kdu_jni.h has:
extern "C"
JNIEXPORT jint JNICALL JNI_OnLoad_kdu_1jni(JavaVM *, void *);
My kdu_jni.cpp has:
JNIEXPORT jint JNICALL JNI_OnLoad_kdu_1jni(JavaVM *vm, void *reserved)
{
return JNI_VERSION_1_8;
}
I have the libkdu_jni.a file in my java.library.path directory when I try to run with the compiled version. It's working fine with a libkdu_jni.so file in that same directory when I try to load it dynamically. When trying with the static file (libkdu_jni.a), I get:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no kdu_jni in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
I've taken out the .so file before trying to load the .a file.
I'm not sure what I'm doing wrong. I don't think it's even seeing the libkdu_jni.a file's JNI_OnLoad_kdu_1jni() because I put an exception in there and I don't see that getting thrown. I've tried several iterations on that name: JNI_OnLoad_kdu_jni(), JNI_OnLoad_kdu_1jni(), JNI_OnLoad(), etc.
Any ideas?
my understanding is it can load static libraries via System.loadLibrary("") if you provide a JNI_OnLoad_L in the *.cpp and *.h files.
Your understanding is incorrect. You can't load a .a file dynamically. It isn't executable in any way shape or form:
infra-library references are not resolved
references outside the library are not resolved either: for example, to the C library.
The link step is essential, and the JVM doesn't do it for you. What you have read applies to libraries statically linked into the JVM.
I suggest you try JNI_OnLoad_kdu_jni as the function name. If that doesn't work, it might not work with library names that contain an underscore.
--- Original post follows ---
Prior to Java 8, only shared object libraries were supported.
This means that to know if the static library is Java 8, a new function must be implemented in the library.
JNI_OnLoad_libname must return a value of JNI_VERSION_1_8 or higher.
I'm guessing since your code works dynamically, but not staticly, perhaps this function is not present. The portion of JEP 178 below lead me to believe this:
The specifications of the java.lang.System.loadLibrary and
java.lang.Runtime.loadLibrary methods will be revised to read:
Loads the native library specified by the libname argument. The libname must not contain any platform-specific prefix, file extension,
or path.
If a native library called libname is statically linked with the VM, then the JNI_OnLoad_libname function exported by the
library is invoked. See the JNI Specification for more details.
Otherwise, the libname is loaded from a system library location and mapped to a native-library image in an
implementation-dependent manner.
Also the notes in the enhancement echo this sentiment
The source code for the loader is helpful
I'd fire up java under debug (gdb) and put a break point in at Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib. You're right, there aren't many great examples.
I'm able to run a program from the commmand line by typing "java main" where main.java and main.class are in the same directory as well as any related classes. This runs fine. When I try to run the same program in Eclipse I get Unsatisfied link errors. I think this is related to the JVM being used. I think that the command line java call is using a different JVM then eclipse. How can you specify which JVM java uses on the command line?
I'm getting an UnsatisfiedLinkError when I run a program in Eclipse that uses native libraries.
This isn't a typical "cannot find...." link error I believe it has actually found the file but there is some other problem.
Exception in thread "main" java.lang.UnsatisfiedLinkError: com.me.this.MyClass.MyMethod(Ljava/lang/String;)I
You can see that if it just could not find the shared library it would say something like:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no MySharedFile.so in java.library.path
So I believe it is finding the file.
Some other issues that are relavent are the fact that if i run the program from the command line instead of in eclipse it finds the .so and runs the program perfectly. Also I had this program running before in a different Eclipse that was using an older 1.6 JVM. I've tried to use that in this eclipse but it hasn't helped.
Is this a problem finding the .so shared file? Or something completely different like I'm using the wrong JVM. I used strace on the java command line program and it appears it's using the new 1.7jdk the same one I'm using now in Eclipse and it will not work.
The .so is in /usr/lib64 and I've also created a -Djava.library.path=... entry in the vm arguments for the run configuration just in case.
I added these try catch around the load:
static
{
try{
System.loadLibrary("MyAwesomeLibrary");
System.out.println("MyAwesomeLibrary library loaded \n");
}
catch(UnsatisfiedLinkError e){
System.out.println("Did not load library");
e.printStackTrace();
}
}
And I get:
MyAwesomeLibrary library loaded
Exception in thread "main" java.lang.UnsatisfiedLinkError: com.me.this.MyClass.MyMethod(Ljava/lang/String;)I
at com.me.this.MyClass.MyMethod(Native Method)
at com.me.this.Main.main(Main.java:8)
It's being called froma main class that looks like this:
public class Main
{
public static void main( String[] args )
{
ClassThatContainsLoadedLIbrary x = new ClassThatContainsLoadedLibrary();
int y = x.Ping( "thisaddress" );
So it appears that it's loading...at least it's getting to the print statement without link errors. the UnsatisfiedLink errors when it actually triest to use the library.
I've been working on this problem for weeks so would really appreciate it if some one had some insight into this. Thanks.
Look at this: http://docs.oracle.com/javase/7/docs/api/java/lang/UnsatisfiedLinkError.html.
Thrown if the Java Virtual Machine cannot find an appropriate native-language definition of a method declared native.
The problem is not with the JVM per se, but with the JVM being unable to find your native libraries. You need to specify the path where the native libraries are stored. This can be done by adding the following as an argument to your JVM in eclipse:
-Djava.library.path=...
Here, take a look at this: http://mindprod.com/jgloss/runerrormessages.html#UNSATISFIEDLINKERROR
If you get the error after the class containing the native method is safely loaded, when you invoke a native method, make sure you generated your *.h file with the fully qualified javah.exe -jni -o mouse.h com.mindprod.mouse.Mouse and not simply javah Mouse
If you get the error after the class containing the native method is safely loaded, when you invoke a native method, check that the *.cpp method signatures exactly match those in the *.h file. You should see method names like this: Java_com_mindprod_mouse_Mouse_GetMousePosition that start with the word Java and contain the package, class and method name all strung together. Make sure you remembered to implement all the methods.
You need to regenerate the *.h and recompile the *.c file if you change the package name.
You should probably go through this list to make sure you're doing all the things correctly.
You should use java in your console to find options for java.
java -version:1.6 MyClass
Right click your project ----> Java Build Path ---> Libraries tab.
Then select JRE System library , and click Edit to bring the following screen to configure
I have a dll file and I am trying to call functions of it through a Java program through JNA
But the problem is It is not able to locate my dll file and throwing the following exception:
java.lang.UnsatisfiedLinkError: Unable to load library 'UsbDll': The specified module could not be found.
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:199)
at com.sun.jna.Native.register(Native.java:1018)
at com.MainClass.<clinit>(MainClass.java:15)
Exception in thread "main"
Below is my program:
package com;
import com.sun.jna.Native
public class MainClass {
static {
Native.register("UsbDll");
}
public native int method();
public static void main(String[] args) {
}
}
The name of my dll file is UsbDll.dll and my operating system is Windows.
============================ EDITED ================================
The location of my dll file is "c:\UsbDll.dll"
When I placed another dll file at the same location, JNA has located it so I think that the problem is with my "UsbDll.dll" file only.
When I tried to load both the dll files (UsbDll.dll and the another dll) with the following command
System.load("c:\\UsbDll.dll");
System.load("c:\\another.dll");
It loaded the "another.dll" successfully but for "UsbDll.dll", it throws the following exception:
java.lang.UnsatisfiedLinkError: C:\UsbDll.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1699)
at java.lang.Runtime.load0(Runtime.java:770)
at java.lang.System.load(System.java:1003)
at com.MainClass.<clinit>(MainClass.java:16)
Exception in thread "main"
Q1. It looks like it is not finding some dependent libraries. But as I am totally new to these dlls, Is there anything I am missing or I need to ask the vendor to provide me the dependent libraries.
OR
Is it depends on some standard libraries which I can download from internet? If it is, then how to find the libraries name on which it depends?
============================ EDITED #2 ================================
I ran the Dependency Walker on my UsbDll.dll file to find the missing dependencies and found the following missing dependencies.
WER.DLL (referred by library WINNM.DLL found in my c:\windows\system32)
IESHIMS.DLL (referred by library WINNM.DLL found in my c:\windows\system32)
WDAPI920.DLL (referred directly by my UsbDll.dll)
Q1. As WINNM.DLL was found in my system32 folder, it seems as the standard dll. And if this standard dll is referring to 2 missing dlls (WER.DLL & IESHIMS.DLL), then I suspect how other applications are working who are using this WINNM.DLL file?
Q2. I googled for WDAPI920.dll (that was referred my UsbDll.dll directly) and many search results appeared with the same dll name. So it also looks like some standard library. So how to fix these dependencies? From where to download them? After downloading, Can I place them in the same directory in which my main dll (UsbDll.dll) is or I need to do something extra to load my dll (UsbDll.dll) sucessfully?
From your edited code it is quite evident that the UsbDll.dll depends on some standard modules which are not there on your system (for example if it uses ATL and if you have don't have proper runtime then it is guaranteed to fail). To resolve this you will need proper runtime environment.
Also it is possible that the dll in concern depends on some vendor specific module. For you the best option is (and fastest option would be) to contact the vendor. Otherwise, try to install proper runtime from the microsoft site (but its more of hit-and-trial)
Update
Use the below links for finding more about DLL dependency:
How do I determine the dependencies of a .NET application?
http://msdn.microsoft.com/en-us/library/ms235265.aspx
Command line tool to find Dll dependencies
Update 2
See the below mentioned link for the missing dll details (but it is specific to the windows version)
Dependency Walker reports IESHIMS.DLL and WER.DLL missing?
http://social.msdn.microsoft.com/Forums/en/vsx/thread/6bb7dcaf-6385-4d24-b2c3-ce7e3547e68b
From few simple google queries, WDAPIXXX.dll appears to be some win driver related thing (although i am not too sure). Check this link, they have something to say about WDAPI http://www.jungo.com/st/support/tech_docs/td131.html.
The DLL must by in the Path specified by LD_LIBRARY_PATH (see your env), or, in the case of JNA, in the current directory.
How can I load a custom dll file in my web application? I've tried the following:
Copied all required dlls in system32 folder and tried to load one of them in Servlet constructor System.loadLibrary
Copied required dlls into tomcat_home/shared/lib and tomcat_home/common/lib
All these dlls are in WEB-INF/lib of the web-application
In order for System.loadLibrary() to work, the library (on Windows, a DLL) must be in a directory somewhere on your PATH or on a path listed in the java.library.path system property (so you can launch Java like java -Djava.library.path=/path/to/dir).
Additionally, for loadLibrary(), you specify the base name of the library, without the .dll at the end. So, for /path/to/something.dll, you would just use System.loadLibrary("something").
You also need to look at the exact UnsatisfiedLinkError that you are getting. If it says something like:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no foo in java.library.path
then it can't find the foo library (foo.dll) in your PATH or java.library.path. If it says something like:
Exception in thread "main" java.lang.UnsatisfiedLinkError: com.example.program.ClassName.foo()V
then something is wrong with the library itself in the sense that Java is not able to map a native Java function in your application to its actual native counterpart.
To start with, I would put some logging around your System.loadLibrary() call to see if that executes properly. If it throws an exception or is not in a code path that is actually executed, then you will always get the latter type of UnsatisfiedLinkError explained above.
As a sidenote, most people put their loadLibrary() calls into a static initializer block in the class with the native methods, to ensure that it is always executed exactly once:
class Foo {
static {
System.loadLibrary('foo');
}
public Foo() {
}
}
Changing 'java.library.path' variable at runtime is not enough because it is read only once by JVM. You have to reset it like:
System.setProperty("java.library.path", path);
//set sys_paths to null
final Field sysPathsField = ClassLoader.class.getDeclaredField("sys_paths");
sysPathsField.setAccessible(true);
sysPathsField.set(null, null);
Please, take a loot at: Changing Java Library Path at Runtime.
The original answer by Adam Batkin will lead you to a solution, but if you redeploy your webapp (without restarting your web container), you should run into the following error:
java.lang.UnsatisfiedLinkError: Native Library "foo" already loaded in another classloader
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1715)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)
at java.lang.Runtime.load0(Runtime.java:787)
at java.lang.System.load(System.java:1022)
This happens because the ClassLoader that originally loaded your DLL still references this DLL. However, your webapp is now running with a new ClassLoader, and because the same JVM is running and a JVM won't allow 2 references to the same DLL, you can't reload it. Thus, your webapp can't access the existing DLL and can't load a new one. So.... you're stuck.
Tomcat's ClassLoader documentation outlines why your reloaded webapp runs in a new isolated ClassLoader and how you can work around this limitation (at a very high level).
The solution is to extend Adam Batkin's solution a little:
package awesome;
public class Foo {
static {
System.loadLibrary('foo');
}
// required to work with JDK 6 and JDK 7
public static void main(String[] args) {
}
}
Then placing a jar containing JUST this compiled class into the TOMCAT_HOME/lib folder.
Now, within your webapp, you just have to force Tomcat to reference this class, which can be done as simply as this:
Class.forName("awesome.Foo");
Now your DLL should be loaded in the common classloader, and can be referenced from your webapp even after being redeployed.
Make sense?
A working reference copy can be found on google code, static-dll-bootstrapper .
You can use System.load() to provide an absolute path which is what you want, rather than a file in the standard library folder for the respective OS.
If you want native applications that already exist, use System.loadLibrary(String filename). If you want to provide your own you're probably better with load().
You should also be able to use loadLibrary with the java.library.path set correctly. See ClassLoader.java for implementation source showing both paths being checked (OpenJDK)
In the case where the problem is that System.loadLibrary cannot find the DLL in question, one common misconception (reinforced by Java's error message) is that the system property java.library.path is the answer. If you set the system property java.library.path to the directory where your DLL is located, then System.loadLibrary will indeed find your DLL. However, if your DLL in turn depends on other DLLs, as is often the case, then java.library.path cannot help, because the loading of the dependent DLLs is managed entirely by the operating system, which knows nothing of java.library.path. Thus, it is almost always better to bypass java.library.path and simply add your DLL's directory to LD_LIBRARY_PATH (Linux), DYLD_LIBRARY_PATH (MacOS), or Path (Windows) prior to starting the JVM.
(Note: I am using the term "DLL" in the generic sense of DLL or shared library.)
If you need to load a file that's relative to some directory where you already are (like in the current directory), here's an easy solution:
File f;
if (System.getProperty("sun.arch.data.model").equals("32")) {
// 32-bit JVM
f = new File("mylibfile32.so");
} else {
// 64-bit JVM
f = new File("mylibfile64.so");
}
System.load(f.getAbsolutePath());
For those who are looking for java.lang.UnsatisfiedLinkError: no pdf_java in java.library.path
I was facing same exception; I tried everything and important things to make it work are:
Correct version of pdf lib.jar ( In my case it was wrong version jar kept in server runtime )
Make a folder and keep the pdflib jar in it and add the folder in your PATH variable
It worked with tomcat 6.
If you believe that you added a path of native lib to %PATH%, try testing with:
System.out.println(System.getProperty("java.library.path"))
It should show you actually if your dll is on %PATH%
Restart the IDE Idea, which appeared to work for me after I setup the env variable by adding it to the %PATH%
The issue for me was naming:
The library name should begin with "lib..." such as libnative.dll.
So you might think you need to load "libnative": System.loadLibrary("libnative")
But you actually need to load "native": System.loadLibrary("native")
Poor me ! spent a whole day behind this.Writing it down here if any body replicates this issue.
I was trying to load as Adam suggested but then got caught with AMD64 vs IA 32 exception.If in any case after working as per Adam's(no doubt the best pick) walkthrough,try to have a 64 bit version of latest jre.Make sure your JRE AND JDK are 64 bit and you have correctly added it to your classpath.
My working example goes here:unstatisfied link error
I'm using Mac OS X Yosemite and Netbeans 8.02, I got the same error and the simple solution I have found is like above, this is useful when you need to include native library in the project. So do the next for Netbeans:
1.- Right click on the Project
2.- Properties
3.- Click on RUN
4.- VM Options: java -Djava.library.path="your_path"
5.- for example in my case: java -Djava.library.path=</Users/Lexynux/NetBeansProjects/NAO/libs>
6.- Ok
I hope it could be useful for someone.
The link where I found the solution is here:
java.library.path – What is it and how to use
It is simple just write java -XshowSettings:properties on your command line in windows and then paste all the files in the path shown by the java.library.path.
I had the same problem and the error was due to a rename of the dll.
It could happen that the library name is also written somewhere inside the dll.
When I put back its original name I was able to load using System.loadLibrary
First, you'll want to ensure the directory to your native library is on the java.library.path. See how to do that here. Then, you can call System.loadLibrary(nativeLibraryNameWithoutExtension) - making sure to not include the file extension in the name of your library.