When loading the library in my main src folder there is no problem, but in the test src folder I get the error. I can still compile and run all the tests normally and they pass.
Both src folder are in the path and I got opencv as a library. Like I said, everything is working, so I guess it's a problem with Eclipse and the display of the error which should not be displayed? So the main problem is that it's visually a pain.
EDIT2 : I just want to say again that everything is working, the tests are all running, it is simply that they pop as problems (and I don't see the errors of the tests because this unspecifiedlinkerror is before and overshadow them)
Also, it does the same thing on both my Windows and Ubuntu machine.
my path is also correct when I print it out right before the System.loadLibrary as .../opencv-2.4.11/build/lib
EDIT3 : I tried Cibin William answer and put my .dll path but to no avail
You can right on the project and click on Build Path -> Configure Build Path -> then select the Libraries tab and select OpenCV jar file and then expend it and then select on Native Library Location and then click on the Edit and then brows the to the .dll file of OpenCV something like this C:\opencv\build\java\x64 Or C:\opencv\build\java\x86 for 32bit System. And it is that.
Or You can load the library by coding (dynamically)
public static void loadOpenCV_Lib() throws Exception {
// get the model
String model = System.getProperty("sun.arch.data.model");
// the path the .dll lib location
String libraryPath = "C:/opencv/build/java/x86/";
// check if system is 64 or 32
if(model.equals("64")) {
libraryPath = "C:/opencv/build/java/x64/";
}
// set the path
System.setProperty("java.library.path", libraryPath);
Field sysPath = ClassLoader.class.getDeclaredField("sys_paths");
sysPath.setAccessible(true);
sysPath.set(null, null);
// load the lib
System.loadLibrary(Core.NATIVE_LIBRARY_NAME);
}
When I run the OpenCV program in eclipse ,unsatisfiedLInkError occurs.I solve the error by exporting the library path in eclipse as follows
1.Right click on the project,seleect Debug as->Debug Configurations...
2.Debug Configuration window appears,Select the Environment tab in the top
3.Click the New button on the right side of the window,A New Environment Variable window appears
4.On the Name type LD_LIBRARY_PATH and in the Value type the folder which contain the .dll file(If the .dll is present in the Lib folder inside the project,type Lib in the Value)
Please try and reply.....
Well, I reinstalled Eclipse and that did it...sigh
The bug was on both Eclipse Luna and Mars Version 4.5.1.
Mars Version 4.5.2 is working fine.
I set up LWJGL 3 in Eclipse, and it's giving me this error when I try to run the test code from https://www.lwjgl.org/guide:
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class org.lwjgl.system.Library
at org.lwjgl.system.MemoryAccess.<clinit>(MemoryAccess.java:22)
at org.lwjgl.system.Pointer.<clinit>(Pointer.java:22)
at org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:594)
at HelloWorld.run(HelloWorld.java:30)
at HelloWorld.main(HelloWorld.java:109)
I made sure that everything is set up correctly, and I just can't place my finger on the problem. What's wrong?
You're missing the native libraries.
As described in this link https://www.lwjgl.org/guide you'll have to setup java.library.path to the native library location.
I downloaded the library and copied the HelloWorld code in the above link in HelloWorld.java inside the directory where I extracted the library.
So the contents inside looks like below
/HelloWorld.java
/build.txt
/doc
/jar
/native
/src.zip
I compiled and ran the HelloWorld.java as below
Compilation (Path separator on linux would be : so there it would be -classpath jar/*:.)
javac -classpath jar/*;. HelloWorld.java
Run
java -classpath jar/*;. -Djava.library.path=native HelloWorld
And this works.
Edit*
I downloaded the library from https://www.lwjgl.org/download (Download Release.)
In eclipse you can add the native library to your path by simply including it on source path. Like below:
There's one more way using which native library can be added per Jar basis.
Expand lwjgl.jar in build path > select native path > click on edit > click workspace > select native directory.
See the images below
I have created a JNI library with visual studio to use in java application and internally this dll calls another DLL (openssl). Now when i load this library with eclipse I get an error saying "Can't find dependent libraries" unless I put the path of the other DLL on the PATH variable.
in thread "main" java.lang.UnsatisfiedLinkError: C:\*****\jniDLL.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1854)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at iwinAlgTest.test.<clinit>(test.java:7)
And I've already tried adding it to -Djava.library.path and to the classpath, and i also included all of my dll and openssl dll and lib files like libeay32.lib but neither worked. Is there a way to do this?
I tried to use Dependency Walker to check if there are any files required by my jniDLL.dll
but i get interesting thing:
what i really do to create my jniDLL:
(jniDLL --> calls myDLL.dll) ==> (myDLL.dll --> calls openssl library)
but Dependency Walker says that
(jniDLL --> depends on myDLL.exe) not myDLL.dll
Note : at first it was a win32 application( which output myDLL.exe) but i changed the project setting to output myDLL.dll then i create another project to create a JNI dll from myDLL.dll which i wrote in c++
One way to bypass this is to load your openssl.dll prior to loading myDLL, so myDLL will find the symbols loaded when it tries to initiate .
Other ways to go around this :
add the openssl.dll to PATH (you already mentioned this)
copy openssl in system32 at install time
put openssl in the same folder as your executable path
This however will only work on Windows.
In linux, you will have to change the rpath inside the .so (but I believe this is out of scope).
I am using eclipse and getting the below error when I try to access a native method from a ExtractImage.dll file-
java.lang.UnsatisfiedLinkError: getVertices
at com.coimp.application.ExtractImage.getVertices(Native Method)
I have added the dll to below paths -
C:\Program Files\Java\jre1.5.0_10\bin;
. //current workspace
C:\WINDOWS\system32;
C:\WINDOWS;
and I have used this method to load the library -
System.loadLibrary("ExtractImage");
Also tried with -
System.load("c:\ExtractImage.dll");
Adding the .dll file to NativeLibrary path
The same code works on my web application.
Geeks, any guesses to fix this problem ?
Thanks for upcoming support.
In the "Run Configuration..." options in the "Arguments" tab specify in "VM Arguments" "-Djava.librar.path=YOUR_DIR_TO_DLL"
If the library has dependencies with other DLLs not present in the PATH, you should also include those directories (separated by ;)
Update
If that fails too you can modifiy PATH environment variable (in tab "Environment"). I would recommend you that you edit the variable (adding your directories) an leave the option "Append environment to native environment" selected (radio buttons at bottom).
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.