My java application depends on a DLL, and that DLL further depends on libstdc++-6.dll.
I tried to:
placed the libstdc++-6.dll in a folder
and put the folder in the %PATH%
Then I meet the java.lang.Unsatisfied LinkError: The specified procedure could not be found when launching application from Eclipse.
But if I put the libstdc++-6.dll into the JDK's bin folder, say C:\Java\jdk1.6.0_45_32bit\bin. It works fine.
But I don't want to pollute the JDK folder. I remember windows will search %PATH% to locate dependent DLLs. Why can't I use the %PATH% in this issue?
Update 1
There are 2 different %PATH% environment variables in Windows.
User variables
System variables
I just accidentally find that:
If I put the DLL's folder to User %PATH%, it cannot be found.
If I put the DLL's folder to System %PATH%, it works.
Why?
Update 2
Inspired by this thread:System versus user PATH environmental variable...winmerge works only if I add the path to the user PATH
I start to wonder maybe my User %Path% is too long. So I moved the folder path containing my dependent DLL from the end of User %PATH% to the beginning. It works now!
At first, I conclude that one who implemented the Windows' DLL lookup algorithm has some truncation issue. And I almost consider it as another annoying Windows Bug.
But I wrote another Windows application which has similar DLL dependencies to confirm my guess. That application works fine! So I have to review my conclusion.
I checked my User %PATH% entry one by one, and place the folder to each possible location. And finally, I find the root cause.
I have a C:\MinGW\bin entry in User %PATH%, which happens to contain a
libstdc++-6.dll (977KB) but unfortunately, which isn't compatible
with the one I need (825KB). It only works if I place my folder before MinGW. So it's actually DLL collision during %PATH% resolution.
Now this issue seems resolved. But another one comes up, do I need to switch back and forth if I want to use both my DLL and the MinGW?
Update 3
Please check the comment by #AndyThomas. He mentioned using System.loadLibrary() for both direct and indirect DLLs. This way, all we need to care about is the java.library.path property. I think that's a once-for-all solution.
First: put all DLL files you need in the same directory
Then: Load native libs - to do so you have 3 options:
Set VM Options while you run your app.
-Djava.library.path="C:\Your Directory where Dll is
present"
Example:
java -Djava.library.path="C:\Your Directory where Dll is
present" -jar app.jar
Load specific native library from within the app:
a) Place the directory that contains the file aaa.dll directly under the Java project.
b) And place this line on the top of stack trace of your app: System.loadLibrary("aaa")
Use VM options from within your app:
System.setProperty( "java.library.path", "C:\Your Directory where Dll is
present" );
Related
Hello This is my code :
if (isWindows()) {
//System.setProperty("jna.library.path", getClass().getResource("/resources/win32-x86").getPath());//netbeans WinOs
System.setProperty("jna.library.path", System.getProperty("user.dir").toString()+File.separator+"Desktop");//compiler WinOs
} else if (isMac()) {
//System.setProperty("jna.library.path", getClass().getResource("/resources").getPath());//netbeans MacOs
System.setProperty("jna.library.path", System.getProperty("user.dir").toString()+File.separator+"Desktop");//compiler MacOs
} else {
System.out.println("Your OS is not support!!");
}
Why I have 2 PATH (don't understand because for add an image i have only one Path) by OS, one for use with IDE and another for use with .JAR ?
I just realized, that when I'm use windows and I run the project (from netbeans) the "Library" load and I get the information, but when I compile and I launch my .jar I get error :
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: %1 is not a valid Win32 application.
My Structure
It is correct?
On mac only work with this command : java -jar "/System/Volumes/Data/Users/hugoclo/NetBeansProjects/Prezauto/dist/Prezauto.jar"since Terminal. If click on jar i have message error : Not Found .....
Sorry about my English,
There can be two reasons for the "why". While Java is cross-platform, JNA (which relies on some native code) must necessarily behave differently on different operating systems. Particularly in the case of loading DLLs (Windows) or dynamic libraries (OSX), you don't want to mix and match. Because it might be possible to have a dll with the same name compiled for different operating systems, JNA's Getting Started page identifies standard locations for these libraries:
Make your target library available to your Java program. There are several ways to do this:
The preferred method is to set the jna.library.path system property to the path to your target library. This property is similar to java.library.path, but only applies to libraries loaded by JNA.
Change the appropriate library access environment variable before launching the VM. This is PATH on Windows, LD_LIBRARY_PATH on Linux, and DYLD_LIBRARY_PATH on OSX.
Make your native library available on your classpath, under the path {OS}-{ARCH}/{LIBRARY}, where {OS}-{ARCH} is JNA's canonical prefix for native libraries (e.g. win32-x86, linux-amd64, or darwin). If the resource is within a jar file it will be automatically extracted when loaded.
In your code, you appear to be trying to do the first option (setting the jna.library.path) to include the user's desktop. That's fine for testing, not good for production, and likely the reason your compiled jar can't find it. Furthermore, by setting this variable, you are overwriting any previous (default) location for it. If you want to go this route, you should copy the saved location and then append your own additional path to it.
However, for code you'll distribute to users, you don't want to have to rely on an absolute file path. It's far better to put the library in a standard relative path location: a resources path (src/main/resources if using Maven) that will be available on your (or any user's) classpath when executing. This seems to align with the commented-out Windows branch of your code, which will look in the win32-x86 subdirectory of your resources folder.
You may have told your IDE to add something to the classpath (so it works there) but if it's not in a standard location, it may fail in a jar.
I'm not sure why the macOS branch of your code does not put the resources in the darwin subdirectory but it probably should.
I currently wrote a simple GUI in Eclipse which runs as intended. I was hoping to export it so I can share it with my friend (who doesn't need to install eclipse and the java libraries). I tried all 3 library handling method Eclipse provides and none of them works. I read a little online and saw something about a manifest file, but wasn't quite sure what to do with it. Is it going to help?
This is where I placed the folder that comes with the .dll file.
This is the result. Am I doing something wrong?
As indicated by the error messages in the first screenshot, what you are missing here is the native library - the software library written and compiled to native code specific to the operating system. What you will need to do is provide the libraries specific to the operating system on which your software will run, eg. dlls for 32 or 64 bit Windows. The manifest does not provide the capability to include those libraries.
When the program is run on Windows, Java will look for native libraries in the following locations:
The current directory
The directories in the PATH environment variable
The directories in java.library.path (if it's specified)
It may be easiest to simply put all files in the one directory. If you do this, you should be able to run the program in the same way as you do now.
The java.library.path option is only needed if you want to put your native library files in a directory separate to the one in which you run your program and not on your PATH. It is only in this case that you will need to add java.library.path, eg. by adding -Djava.library.path=c:\path\to\your\lib after java. Also note that you may use a relative path, ie. a path that is relative to the directory you are in when you execute the command.
I also see from your later error messages that you have another dependency, but on a java library LeapJava.jar. As running a jar with -jar will only work if you have a single jar, but because you have more than one (your own program plus the dependency), you'll instead need to use the -classpath (or -cp for short) argument and add your main class. The classpath argument is a semicolon-separated list of classpath locations, while the main class is the one containing your public static void main method, eg. your.package.name.YourMainClass. So assuming your UI.jar is still in C:\Users\Ian\Desktop\Leap Data UI, you should be able to navigate to that directory and execute with:
java -cp UI.jar;UI_lib\LeapJava.jar -Djava.library.path="UI_lib\x64" your.package.name.YourMainClass
I wrote desktop program in Java on Windows 7 and hanged it on startup by writing to registry the path of jar file (kind of C:\Users\User\Documents\My App.jar) in HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Run branch. When my program loads with Windows, it must load some text file that placed in the same folder as the program:
File f = new File("text.txt"); // without full path to file
if(!f.exists())
JOptionPane.showMessageDialog(null, "File not found: " + f.getAbsolutePath());
but cant do it and I get message: "File not found: C:\Windows\system32\text.txt". It appears as if the program is located in the system32 folder and a text file, respectively, too. What did I do wrong?
My theory: if you installed Java for Windows via the traditional installer, in addition to the place you told it to put it (canonically, JAVA_HOME), the installer drops a java.exe in the system32 directory, so it's likely that when you're starting the JVM on startup, system32 is the working directory and that's where it will look for files with relative path names like the one you've provided.
The easiest solution is to specify the path to the text file absolutely in your code. I would also recommend specifying the full path to java.exe in your registry key (I would guess that right now it's just java.exe with no path) so that you can guarantee which version you're running; if you have multiple versions of Java installed only the most recently one installed will have java.exe in system32 and without a qualifying path I would guess that's the one you're getting since PATH will probably be minimal at that point.
As a closing--unrelated to your problem--point, I hate that Java does this on Windows and wipe that copy of java.exe out immediately, and then set up PATH to make sure the version I want is the one that is executed on demand.
You need to get current working directory and use it as a part of absolute path to a file.
Take a look at this question: Getting the Current Working Directory in Java
The other workaround would be to read this registry key you described and using this information to read a file from desired path - read/write to Windows Registry using Java
The path that you are referring is the working directory, and is not where the application is installed. Like if you put a shorcut to it, you can change the working directory and it will change the result you are getting. But as you put it to startup automatically, probably windows is setting this as the working directory.
Like that:
Use registry to startup a program, and also change the current working directory? 1
You can try to pass the file directory to your app with a command line parameter in the registry.
1 - This probably won't solve the problem for you, don't seems you have one, its just an explanation
I think that #Omaha's answer is describing what is going on (you are launching java.exe from the system32 directory - the JRE installer places a copy of java.exe in system32 to make it easier for users to access).
The actual solution to your situation is to adjust your CurrentVersion\Run registry entry so it specifies a default working folder for the application. Check out: Use registry to startup a program, and also change the current working directory?
How do I connect to the gdal eclipse. I tried all the ways it does not work.
How do I connect to the gdal eclipse. I tried all the ways it does not work.
All the time issue
java.lang.UnsatisfiedLinkError: D: \ Document \ JAVA \ Gdal \ gdalLibrary \ gdaljni.dll: Can't find dependent libraries
I also have this problem and just found a solution. I am working with WIN8, and downloaded release-1600-gdal-1-8-0-mapserver-5-6-6.zip. As in the readme txt, I run the SDKShell.bat to set the environment. Then I include the jar and the four jni dlls in the java folder into my testing java project. There was always error like gdaljni.dll: Can't find dependent libraries. Then I figured out the settings in the bat may not been successfully done. I opened up the bat with an editor and found all the necessary enviroment settings and did it one by one. Then the java project worked with no problem. The settings needed are as follows:
SET PATH=%CD%\bin;%CD%\bin\proj\apps;%CD%\bin\gdal\apps;%CD%\bin\ms\apps;%PATH%
SET GDAL_DATA=%CD%\bin\gdal-data
SET GDAL_DRIVER_PATH=%CD%\bin\gdal\plugins
SET PROJ_LIB=%CD%\bin\proj\SHARE
For the PATH you can just in explorer right click on computer-properties-advanced system settings-Change enviroment variables. Add the absolute paths(%CD% means the current folder of the bat file, in my case is C:\GDAL, so path "%CD%\bin" should be changed into "C:\GDAL\bin") of "SET PATH line" to your PATH. For the other three lines of settings, just add three system variable for each and aslo change the path containing %CD% into abousolute paths. Then, everything should be ok. Note I omitted some paths in the bat file which I do not need for my java bindings. You can also add them to PATH if you want to do use gdal with other languages. I guess the most common mistake is forgetting to add the GDAL_DRIVER_PATH and PROJ_LIB.Hope it may be helpful for the others who have such issue.
If UnsatisfiedLinkError: gdaljni.dll: Can't find dependent libraries occurs...
Check the path of GDAL libraries, data and plugins (they must be in the installation path of your application)
Missing VC++2010 runtime (if GDAL is compiled using VC++2010): download the Microsoft Visual C++ 2010 Redistributable Package:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84
You may need to set following in the Windows system environment variables:
GDAL_DATA=<path to gdal-data folder>
GDAL_DRIVER=<path to your gdal\plugins folder>
This might help you:
1) set path as said above
2) Put the *jni.dll files in the 'The path where you installed gdal'\gdallib\bin\gdal\java\ directories into the jre\bin directories that you are using. (This saved me!)
Hope it will be helpful:)
I got a native library that needs to be added to java.library.path. With JVM argument -Djava.library.path=path... I can set the path as I want.
My problem is that my other library (pentaho reporting) searches fonts based on the default java.library.path (including system directories etc) and the manual setting overrides the default path..
So : how can I add a path entry to the default java.library.path instead of overriding it (which seems to be done with -Djava.library.path)? (I wouldn't want to add the default path by hand, which wouldn't be nice for the sake of deployment)
EDIT: Sorry for missing details; I'm working with Eclipse. (The deployment is done with JNLP and there I can use nativelib under resources)
Had forgotten this issue... I was actually asking with Eclipse, sorry for not stating that originally.
And the answer seems to be too simple (at least with 3.5; probably with older versions also):
Java run configuration's Arguments : VM arguments:
-Djava.library.path="${workspace_loc:project}\lib;${env_var:PATH}"
Must not forget the quotation marks, otherwise there are problems with spaces in PATH.
If you want to add a native library without interfering with java.library.path at development time in Eclipse (to avoid including absolute paths and having to add parameters to your launch configuration), you can supply the path to the native libraries location for each Jar in the Java Build Path dialog under Native library location. Note that the native library file name has to correspond to the Jar file name. See also this detailed description.
SWT puts the necessary native DLLs into a JAR. Search for "org.eclipse.swt.win32.win32.x86_3.4.1.v3449c.jar" for an example.
The DLLs must be in the root of the JAR, the JAR must be signed and the DLL must appear with checksum in the META-INF/MANIFEST.MF for the VM to pick them up.
In Windows, like this:
-Djava.library.path="C:/MyLibPath;%PATH%"
%PATH% is your old -Djava.library.path
Can you get round this by calling System.load() programmatically to load your native library? This method (unlike System.loadLibrary()) allows you to specify an absolute path.
In UNIX systems, you can append to the LD_LIBRARY_PATH environment variable. On Windows, the JVM automatically sets the system property, java.library.path, to PATH; so if the dll is on your PATH, then you're set.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=102239 states that there is no substitution mechanics implemented in Eclipse's launcher, at least no up to release Juno.
Thus it is (almost) impossible to append or prepend another library folder to java.library.path when launching Eclipse without prior knowledge of the default setting.
I wrote almost, cause it should be possible to let Eclipse startup, dump the content of java.library.path and stop Eclipse in one command. The dump would the be parsed and then taken as the input for launching Eclipse, i.e.
#!/bin/bash
# get default value of java.library.path (somehow)
default_lib_path=$( start_dump_stop_eclipse_somehow )
# now launch Eclipse
eclipse --launcher.appendVmargs \
-vmargs \
-Djava.library.path="/my/native/lib/folder:${default_lib_path}"
On Windows: Add the path to the library to the PATH environment variable.
On Linux: Add the path to the library to the LD_LIBRARY_PATH environment variable.
On Mac: Add the path to the library to the DYLD_LIBRARY_PATH environment variable.
java.library.path is initilized with the values of the variables above on its corresponding platform.
This should work on any IDE.
You can test if the value is what you expect by calling java -XshowSettings:properties
The solution offered by Rob Elsner in one of the comments above works perfectly (OSX 10.9, Eclipse Kepler). One has to append their additional paths to that separated by ":".
You could also use ${system_property:java.library.path} – Rob Elsner Nov 22 '10 at 23:01
Window->Preferences->Java->Installed JREs.
Choose your current
JRE(JDK) and click Edit.
Fill Default VM Arguments:
-Djava.library.path=/usr/local/xuggler/lib.
The native library file name has to correspond to the Jar file name. This is very very important.
Please make sure that jar name and dll name are same.
Also,please see the post from Fabian Steeg
My download for jawin was containing different names for dll and jar.
It was jawin.jar and jawind.dll, note extra 'd' in dll file name.
I simply renamed it to jawin.dll and set it as a native library in eclipse as mentioned in post
"http://www.eclipsezone.com/eclipse/forums/t49342.html"
For some reason I couldn't get multiple folders to work (well it did for a while but as soon as I needed more dlls and added more folders, none with white spaces in the path). I then copied all needed dlls to one folder and had that as my java.library.path and it worked. I don't have an explanation - if anyone does, it would be great.
Many of the existing answers assume you want to set this for a particular project, but I needed to set it for Eclipse itself in order to support integrated authentication for the SQL Server JDBC driver.
To do this, I followed these instructions for launching Eclipse from the Java commandline instead of its normal launcher. Then I just modified that script to add my -Djava.library.path argument to the Java commandline.
On Windows, I have found that the important thing is to start Eclipse from the command line rather than from the Start Menu or a shortcut, provided that the native DLL is in a directory in your PATH. Apparently, this ensures that the proper directory is on the path.