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:)
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.
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" );
I'm having a difficult time figuring this one out. I have an eclipse project where I created a user library which includes the jar file opencv_java245.jar.
I've tried everything I can think of, adding the jar to the path, adding the directory of the jar to the path variable.
I checked my java versions, I've tried VM arguments in run config.
I still get the same UnsatisfiedLinkError on this line System.loadLibrary("opencv_java245");
Right now I have a user library with opencv-245.jar located in C:\OpenCV\opencv\build\java
The Native Library Location for it is located in C:/OpenCV/opencv/build/java
My PATH variable also has that same location added to it.
System.loadLibrary(Core.NATIVE_LIBRARY_NAME);
this the code for detect default dll file..
Actually for future reference for anyone I found the solution. Inside the java folder for OpenCV there is a x64 and x86 folder containing dll files for OpenCV. Copy over either 64 bit or 32 bit dll file to your java folder for OpenCV and it should work.
I unsuccessfully attempted to install Groovy 1.8.6 (zip distribution) on a Win XP (sp3) machine yesterday and today (the error messages stated it was unable to find the groovyStarter then I received a lengthy stack trace...). Needless to say, it was a frustrating experience. So, I decided to use the Windows installer for version 1.8.5. Groovysh functions as it should but if I write a small Groovy script and place it in a file:
println "Hello Groovy Programmer!"
...no output is displayed. Using groovy -e "println 'Hello!'" has the exact same behavior.
Any ideas of what might cause this?
Thanks.
~Caitlin
I'm not sure what you mean by "installing" the binary ZIP distribution. You don't really install anything in the usual sense of the term... you just unzip the ZIP file wherever you like. On my Windows XP laptop, I unzipped its contents into C:\groovy-1.8.6\.
I have heard some people complain of problems when they unzip into a path that contains spaces (such as C:\Documents and Settings\YourUsername\Desktop)... so perhaps that could be your issue, if you unzipped to your Desktop or something.
Just unzip the ZIP file somewhere, and add it's /bin directory to your PATH. On a Windows XP machine:
Right-click "My Computer"
Select "Properties"
Go to the "Advanced" tab
Click the "Environment Variables" button
Edit the PATH variable, and add C:\groovy-1.8.6\bin (or whatever)
The Groovy installation instructions also suggest that you add a GROOVY_HOME variable (pointing to C:\groovy-1.8.6), and a JAVA_HOME variable pointing to the root directory of your Java JDK (not the JRE located inside of the JDK). However, to be honest, I only remember to add these two environment variables half the time when putting Groovy on a a new machine, and it's never caused me problems.
With the ZIP file unzipped, and its /bin directory in your PATH, you just open a command-prompt and type:
groovy <script name>
... or, to run the GUI interface:
groovyConsole
If by chance you saw those "groovyStarter" errors because you tried to run startGroovy, then use one of the two commands above instead. The "startGroovy.bat" command is an internal script intended for indirect use through the other scripts under /bin. It will throw a java.lang.ClassNotFoundException: org.codehaus.groovy.tools.GroovyStarter stacktrace if you call it directly... because it needs one of the other scripts to set some variable prior to calling it.
Good luck!
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.