Related
I'm working on a Java project that uses the JNI. The JNI calls a custom library that I've written myself, let's say mylib.dll, and that depends on a 3rd party library, libsndfile-1.dll.
When I run my program it crashes with
java.lang.UnsatisfiedLinkError: C:\...path...\mylib.dll: Can't find dependent libraries.
I've searched this site (and others) and I've tried a number of fixes:
I ran dependency walker. DW gave a couple of warnings -- that two libraries required by libsndfile, MPR.DLL and SHLWAPI.DLL, had "unresolved imports" -- but the DW FAQ said that these warnings could be safely ignored.
I fixed the method names in mylib.dll, as suggested here. The method names had somehow gotten mangled by the compiler, but I added linker flags and the dll method names now match those in my jni header file exactly.
I put all of these DLLs in the same directory -- the same directory as the .jar that calls them -- to ensure that they're on the right PATH.
No dice.
Does anyone have any idea what's going on?
I'm doing my development in Visual Studio 2010 on a MacBook pro (via Parallels). I'm doing my testing in Windows XP on a toshiba laptop.
I'm pretty sure the classpath and the shared library search path have little to do with each other. According to The JNI Book (which admittedly is old), on Windows if you do not use the java.library.path system property, the DLL needs to be in the current working directory or in a directory listed in the Windows PATH environment variable.
Update:
Looks like Oracle has removed the PDF from its website. I've updated the link above to point to an instance of the PDF living at University of Texas - Arlington.
Also, you can also read Oracle's HTML version of the JNI Specification. That lives in the Java 8 section of the Java website and so hopefully will be around for a while.
Update 2:
At least in Java 8 (I haven't checked earlier versions) you can do:
java -XshowSettings:properties -version
to find the shared library search path. Look for the value of the java.library.path property in that output.
I want to inform this interesting case, after tried all the above method, the error is still there. The weird thing is it works on a Windows 7 computer, but on Windows XP it is not. Then I use dependency walker and found on the Windows XP there is no VC++ Runtime as my dll requirement. After installing VC++ Runtime package here it works like a charm. The thing that disturbed me is it keeps telling Can't find dependent libraries, while intuitively the JNI dependent dll is there, however it finally turns out the JNI dependent dll requires another dependent dl. I hope this helps.
You need to load your JNI library.
System.loadLibrary loads the DLL from the JVM path (JDK bin path).
If you want to load an explicit file with a path, use System.load()
See also: Difference between System.load() and System.loadLibrary in Java
If you load a 32 bit version of your dll with a 64 bit JRE you could have this issue. This was my case.
Please verify your library path is right or not. Of course, you can use following code to check your library path path:
System.out.println(System.getProperty("java.library.path"));
You can appoint the java.library.path when launching a Java application:
java -Djava.library.path=path ...
Did have identical problem with on XP machine when installing javacv and opencv in combination with Eclipse. It turned out that I was missing the following files:
msvcp100.dll
msvcr100.dll
Once these were installed, the project compiled and ran OK.
When calling System.loadLibrary(), the JVM will look on the java.library.path for your native library. However, if that native library declares any dependencies on other native libraries, then the operating system will be tasked with finding those native library dependencies.
Since the operating system has no concept of the java.library.path, it will not see any directories you place on the java.library.path. Instead, it will only search the directories on PATH environment variable of the operating system. This is totally fine if the native library dependency is an operating system native library because it will be found on the PATH. However, if the native library dependency is a native library that you or someone else created, then it will not be found on the PATH unless you place it there. This behavior is strange, unexpected, and not well documented, but it is documented in the OpenJDK issue tracker here. You can also find another StackOverflow answer reinforcing this explanation, here.
So, you have a couple of options. You could either load each native library in the correct dependency order using System.loadLibrary(), or you could modify the PATH to include the directories where your native libraries are stored.
Short answer: for "can't find dependent library" error, check your $PATH (corresponds to bullet point #3 below)
Long answer:
Pure java world: jvm uses "Classpath" to find class files
JNI world (java/native boundary): jvm uses "java.library.path" (which defaults to $PATH) to find dlls
pure native world: native code uses $PATH to load other dlls
I found a great article by some friends at keepsafe that went through the same thing I did. It worked for me, so hopefully it helps you out as well! Have a read if you're interested (The Perils of Loading Native Libraries on Android) or just use
compile 'com.getkeepsafe.relinker:relinker:1.2.3'
and replace
System.loadLibrary("myLibrary");
with
ReLinker.loadLibrary(context, "mylibrary");
installing Microsoft Visual C++ 2010 SP1 Redistributable Fixed it
I used to have exactly the same problem, and finally it was solved.
I put all the dependent DLLs into the same folder where mylib.dll was stored and make sure the JAVA Compiler could find it (if there is no mylib.dll in the compilation path, there would be an error reporting this during compiling). The important thing you need to notice is you must make sure all the dependent libs are of the same version with mylib.dll, for example if your mylib.dll is release version then you should also put the release version of all its dependent libs there.
Hope this could help others who have encountered the same problem.
I had the same issue, and I tried everything what is posted here to fix it but none worked for me.
In my case I'm using Cygwin to compile the dll. It seems that JVM tries to find the JRE DLLs in the virtual Cygwin path.
I added the the Cygwin's virtual directory path to JRE's DLLs and it works now.
I did something like:
SET PATH="/cygdrive/c/Program Files/Java/jdk1.8.0_45";%PATH%
In my situation, I was trying to run a java web service in Tomcat 7 via a connector in Eclipse. The app ran well when I deployed the war file to an instance of Tomcat 7 on my laptop. The app requires a jdbc type 2 driver for "IBM DB2 9.5". For some odd reason the connector in Eclispe could not see or use the paths in the IBM DB2 environment variables, to reach the dll files installed on my laptop as the jcc client. The error message either stated that it failed to find the db2jcct2 dll file or it failed to find the dependent libraries for that dll file. Ultimately, I deleted the connector and rebuilt it. Then it worked properly. I'm adding this solution here as documentation, because I failed to find this specific solution anywhere else.
Creating static library worked for me, compiling using g++ -static. It bundles the dependent libraries along with the build.
place the required dlls in folder and set the folder path in PATH environment variable.
make sure updated environment PATH variable is reflected.
I was facing same issue with ffmpeg library after merging two Android projects as one project.
Actually issue was arriving due to two different versions of ffmpeg library but they were loaded with same names in memory. One library was placed in JNiLibs while other was inside another library used as module. I was not able to modify the code of module as it was readonly so I renamed the one used in my own code to ffmpegCamera and loaded it in memory with same name.
System.loadLibrary("ffmpegCamera");
This resolved the issue and now both versions of libraries are loading well as separate name and process id in memory.
I faced the same problem after migrating my CI into a new machine.
I was still facing it even after applying all the above solutions.
The problem was in my new machine, there was Microsoft Visual C++ 2010 SP1 Redistributable x86 installed in it. But my new machine was having 64-bit CPU and operating system. So the fix was that i just updated and installed the 64 bit version from here .
Go to http://tess4j.sourceforge.net/usage.html and click on Visual C++ Redistributable for VS2012
Download it and run VSU_4\vcredist_x64.exe or VSU_4\vcredist_x84.exe depending upon your system configuration
Put your dll files inside the lib folder, along with your other libraries (eg \lib\win32-x86\your dll files).
I am trying to use a library called Journey browser which uses the Java Chromium Embedded Framework. I first created a Java Maven Project with Netbeans and I edited the pom.xml to match the values on the library's guide, which is here: https://github.com/CodeBrig/Journey, to add the maven dependencies. (No errors detected by Netbeans) I then built the project to download the maven dependency and put their default code (modified slightly) in the main class. Netbeans found no errors in the code. However, when I run the project I get a "no chrome_elf in java.library.path". I think this has something to do with embedding JCEF, but I am not sure how to add this to the "java.library.path" in Netbeans.
How do I fix this "chrome_elf" problem?
Also, if I am able to fix this will it be an error for production if someone doesn't have "chrome_elf" installed?
For Windows
This happens because the chrome_elf.dll (on Windows) file cannot be found.
Java is looking for this file on java.library.path - which (on my machine, anyway) refers to all the locations referenced by the Windows %path% environment variable.
One way to fix this is to download one of the pre-built distributions from that GitHub page (for example the Windows one, referred to here):
https://github.com/CodeBrig/Journey/releases/download/0.4.0-78-assets/jcef-distrib-windows64.zip
Then unzip the resulting jcef-distrib-windows64.zip. In the win64\bin\lib\win64 directory under that main directory you will find the chrome_elf.dll you need - and other binaries which are also needed.
Add this directory to your path - either by adding it to the Windows environment variable or via java -Djava.library.path=....
For example, the path may be similar to this:
C:\your\path\to\jcef-distrib-windows64\win64\bin\lib\win64
This should allow you to run the demo code provided in the JourneyBrowser class. A browser window should open as a result.
Here is the browser:
The above steps worked for me - and the only files I needed to keep from the (large) distribution download were those in the jcef-distrib-windows64\win64\bin\lib\win64 directory. It's possible that I already have some other dependencies which may be needed - so I cannot guarantee this process will also work for you.
For Linux (and MacOS)
I have not tried this on a Linux machine. But in that case, I believe you will need to download and unzip the jcef-distrib-linux64 release - and then point to the jcef-distrib-linux64\linux64\bin\lib\linux64 directory, containing libcef.so and other libraries.
Similarly for MacOS, there is a distribution which can be downloaded and unzipped.
Alternative
An alternative is to simply use the pre-built distributions provided on GitHub, using the commands provided. Obviously, in this case, you will not be creating your own customized implementation (so, no JourneyBrowser class).
copy scr/native/Release to jcef_build/native/Release from the default output directory of VS.check whether the Release exists in java.lib.path
I'm working on a Java project that uses the JNI. The JNI calls a custom library that I've written myself, let's say mylib.dll, and that depends on a 3rd party library, libsndfile-1.dll.
When I run my program it crashes with
java.lang.UnsatisfiedLinkError: C:\...path...\mylib.dll: Can't find dependent libraries.
I've searched this site (and others) and I've tried a number of fixes:
I ran dependency walker. DW gave a couple of warnings -- that two libraries required by libsndfile, MPR.DLL and SHLWAPI.DLL, had "unresolved imports" -- but the DW FAQ said that these warnings could be safely ignored.
I fixed the method names in mylib.dll, as suggested here. The method names had somehow gotten mangled by the compiler, but I added linker flags and the dll method names now match those in my jni header file exactly.
I put all of these DLLs in the same directory -- the same directory as the .jar that calls them -- to ensure that they're on the right PATH.
No dice.
Does anyone have any idea what's going on?
I'm doing my development in Visual Studio 2010 on a MacBook pro (via Parallels). I'm doing my testing in Windows XP on a toshiba laptop.
I'm pretty sure the classpath and the shared library search path have little to do with each other. According to The JNI Book (which admittedly is old), on Windows if you do not use the java.library.path system property, the DLL needs to be in the current working directory or in a directory listed in the Windows PATH environment variable.
Update:
Looks like Oracle has removed the PDF from its website. I've updated the link above to point to an instance of the PDF living at University of Texas - Arlington.
Also, you can also read Oracle's HTML version of the JNI Specification. That lives in the Java 8 section of the Java website and so hopefully will be around for a while.
Update 2:
At least in Java 8 (I haven't checked earlier versions) you can do:
java -XshowSettings:properties -version
to find the shared library search path. Look for the value of the java.library.path property in that output.
I want to inform this interesting case, after tried all the above method, the error is still there. The weird thing is it works on a Windows 7 computer, but on Windows XP it is not. Then I use dependency walker and found on the Windows XP there is no VC++ Runtime as my dll requirement. After installing VC++ Runtime package here it works like a charm. The thing that disturbed me is it keeps telling Can't find dependent libraries, while intuitively the JNI dependent dll is there, however it finally turns out the JNI dependent dll requires another dependent dl. I hope this helps.
You need to load your JNI library.
System.loadLibrary loads the DLL from the JVM path (JDK bin path).
If you want to load an explicit file with a path, use System.load()
See also: Difference between System.load() and System.loadLibrary in Java
If you load a 32 bit version of your dll with a 64 bit JRE you could have this issue. This was my case.
Please verify your library path is right or not. Of course, you can use following code to check your library path path:
System.out.println(System.getProperty("java.library.path"));
You can appoint the java.library.path when launching a Java application:
java -Djava.library.path=path ...
Did have identical problem with on XP machine when installing javacv and opencv in combination with Eclipse. It turned out that I was missing the following files:
msvcp100.dll
msvcr100.dll
Once these were installed, the project compiled and ran OK.
When calling System.loadLibrary(), the JVM will look on the java.library.path for your native library. However, if that native library declares any dependencies on other native libraries, then the operating system will be tasked with finding those native library dependencies.
Since the operating system has no concept of the java.library.path, it will not see any directories you place on the java.library.path. Instead, it will only search the directories on PATH environment variable of the operating system. This is totally fine if the native library dependency is an operating system native library because it will be found on the PATH. However, if the native library dependency is a native library that you or someone else created, then it will not be found on the PATH unless you place it there. This behavior is strange, unexpected, and not well documented, but it is documented in the OpenJDK issue tracker here. You can also find another StackOverflow answer reinforcing this explanation, here.
So, you have a couple of options. You could either load each native library in the correct dependency order using System.loadLibrary(), or you could modify the PATH to include the directories where your native libraries are stored.
Short answer: for "can't find dependent library" error, check your $PATH (corresponds to bullet point #3 below)
Long answer:
Pure java world: jvm uses "Classpath" to find class files
JNI world (java/native boundary): jvm uses "java.library.path" (which defaults to $PATH) to find dlls
pure native world: native code uses $PATH to load other dlls
I found a great article by some friends at keepsafe that went through the same thing I did. It worked for me, so hopefully it helps you out as well! Have a read if you're interested (The Perils of Loading Native Libraries on Android) or just use
compile 'com.getkeepsafe.relinker:relinker:1.2.3'
and replace
System.loadLibrary("myLibrary");
with
ReLinker.loadLibrary(context, "mylibrary");
installing Microsoft Visual C++ 2010 SP1 Redistributable Fixed it
I used to have exactly the same problem, and finally it was solved.
I put all the dependent DLLs into the same folder where mylib.dll was stored and make sure the JAVA Compiler could find it (if there is no mylib.dll in the compilation path, there would be an error reporting this during compiling). The important thing you need to notice is you must make sure all the dependent libs are of the same version with mylib.dll, for example if your mylib.dll is release version then you should also put the release version of all its dependent libs there.
Hope this could help others who have encountered the same problem.
I had the same issue, and I tried everything what is posted here to fix it but none worked for me.
In my case I'm using Cygwin to compile the dll. It seems that JVM tries to find the JRE DLLs in the virtual Cygwin path.
I added the the Cygwin's virtual directory path to JRE's DLLs and it works now.
I did something like:
SET PATH="/cygdrive/c/Program Files/Java/jdk1.8.0_45";%PATH%
In my situation, I was trying to run a java web service in Tomcat 7 via a connector in Eclipse. The app ran well when I deployed the war file to an instance of Tomcat 7 on my laptop. The app requires a jdbc type 2 driver for "IBM DB2 9.5". For some odd reason the connector in Eclispe could not see or use the paths in the IBM DB2 environment variables, to reach the dll files installed on my laptop as the jcc client. The error message either stated that it failed to find the db2jcct2 dll file or it failed to find the dependent libraries for that dll file. Ultimately, I deleted the connector and rebuilt it. Then it worked properly. I'm adding this solution here as documentation, because I failed to find this specific solution anywhere else.
Creating static library worked for me, compiling using g++ -static. It bundles the dependent libraries along with the build.
place the required dlls in folder and set the folder path in PATH environment variable.
make sure updated environment PATH variable is reflected.
I was facing same issue with ffmpeg library after merging two Android projects as one project.
Actually issue was arriving due to two different versions of ffmpeg library but they were loaded with same names in memory. One library was placed in JNiLibs while other was inside another library used as module. I was not able to modify the code of module as it was readonly so I renamed the one used in my own code to ffmpegCamera and loaded it in memory with same name.
System.loadLibrary("ffmpegCamera");
This resolved the issue and now both versions of libraries are loading well as separate name and process id in memory.
I faced the same problem after migrating my CI into a new machine.
I was still facing it even after applying all the above solutions.
The problem was in my new machine, there was Microsoft Visual C++ 2010 SP1 Redistributable x86 installed in it. But my new machine was having 64-bit CPU and operating system. So the fix was that i just updated and installed the 64 bit version from here .
Go to http://tess4j.sourceforge.net/usage.html and click on Visual C++ Redistributable for VS2012
Download it and run VSU_4\vcredist_x64.exe or VSU_4\vcredist_x84.exe depending upon your system configuration
Put your dll files inside the lib folder, along with your other libraries (eg \lib\win32-x86\your dll files).
Good day. I have the following problem. I have a code of application written on Java, which uses external jar library(no sources). This jar library inside loads external native library, which is set up with java.library.path system property. This external native library is DLL. The problem is to run this program in Ubuntu. Ubuntu wants to see not .dll as a library, but .so and there is no .so file available for this program, only .dll. Is there any way to convert .dll to .so or run this program using wine(Ubuntu tool), for example, some how, or any other way?
Will be very thank for help
A .dll file is a Windows format library. You might be able to run it under a Windows emulator in Linux (such as Wine) but there is no way to use it in a native Linux application.
I have a java application using an external dll (zmq). When I run it in debug mode in Eclipse it's all fine. However, when I export the application as Runnable JAR file then trying to run it, I'm getting that error referencing the dll.
Following my research on this site I configured the build path for JRE System Library, added that path of the folder containing the dll to Native library location, but I'm still getting that error.
Is there anything I need to do further? Or different?
Thanks.
JZMQ needs two things to run: zmq.dll (the native ZMQ library) and jzmq.dll (the "bridge" library between Java and ZMQ). The particular error you are getting means your compile environment can't locate jzmq.dll; you just need to specify the path where it can find jzmq.dll. Note that, as far as I'm aware, there is no way for jzmq.dll to be in a JAR file so you can just include it in your classpath.
Unfortunately, I can't tell you exactly how to do it in Windows. I come from Linux, where DLLs are SO files. There it would be a simple export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/jzmq.