[gdal-dev] JRE vs JDK
Hi there, I am getting this exception when loading gdal.jar: * Native library load failed. java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I * If I change the script that launch my application to use the "java.exe" from the JDK instead of the JRE then the problem is gone. The problem is that users usually have only JRE. Right? Anyway, It doesn't seems like there is nothing wrong with the GDAL built. I also try the same test with Tamas' binaries but got the same strange error. An by looking at swig/include/java/*.i I can see that some of the loadLibrary would issue that message before the exception. "WARNING : GDAL should be compiled with thread support for safe execution in Java." But I am not getting it. So the error must be coming from loading "gdalconstjni.dll" or "osrjni.dll" but not "gdaljni.dll" or "ogrjni.dll" I haven't tried that with Linux but I will. I search for "java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I" on the web there are a hand full of question about that but none of the suggestions mentioned the JRE vs JDK issue. Does anybody has a clue? Regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JRE vs JDK
Le vendredi 26 octobre 2012 17:52:18, Ivan Lucena a écrit : > Hi there, > > I am getting this exception when loading gdal.jar: > > * > Native library load failed. > java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I > * > > If I change the script that launch my application to use the "java.exe" > from the JDK instead of the JRE then the problem is gone. The problem is > that users usually have only JRE. Right? > > Anyway, It doesn't seems like there is nothing wrong with the GDAL built. I > also try the same test with Tamas' binaries but got the same strange > error. > > An by looking at swig/include/java/*.i I can see that some of the > loadLibrary would issue that message before the exception. > > "WARNING : GDAL should be compiled with thread support for safe execution > in Java." > > But I am not getting it. So the error must be coming from loading > "gdalconstjni.dll" or "osrjni.dll" but not "gdaljni.dll" or "ogrjni.dll" > > I haven't tried that with Linux but I will. > > I search for "java.lang.UnsatisfiedLinkError: > org.gdal.gdal.gdalJNI.HasThreadSupport()I" on the web there are a hand > full of question about that but none of the suggestions mentioned the JRE > vs JDK issue. > > Does anybody has a clue? I'm a bit skeptical about this being a JRE vs JDK issue. I suspect that you have an issue with the supporting dll (the 4 jni ones and gdalXXX.dll and its dependencies) not being found in the PATH. I've just tried with an older release-1500-dev.zip from Tamas site and a JRE. I put gdalinfo.class (compiled from the samples in swig/java/apps) in C: \release-1500-dev\release-1500\bin\gdal\java And then, after calling SDKShell.bat, just run from there : C:\release-1500-dev\release-1500\bin\gdal\java>java -cp gdal.jar;. gdalinfo Seems to work. Regards, Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JRE vs JDK
Hi Even, > ---Original Message--- > From: Even Rouault > To: gdal-dev@lists.osgeo.org, Ivan Lucena > Subject: Re: [gdal-dev] JRE vs JDK > Sent: Oct 26 '12 13:26 > > Le vendredi 26 octobre 2012 17:52:18, Ivan Lucena a écrit : > > Hi there, > > > > I am getting this exception when loading gdal.jar: > > > > * > > Native library load failed. > > java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.HasThreadSupport()I > > * > > > > If I change the script that launch my application to use the "java.exe" > > from the JDK instead of the JRE then the problem is gone. The problem is > > that users usually have only JRE. Right? > > > > Anyway, It doesn't seems like there is nothing wrong with the GDAL built. I > > also try the same test with Tamas' binaries but got the same strange > > error. > > > > An by looking at swig/include/java/*.i I can see that some of the > > loadLibrary would issue that message before the exception. > > > > "WARNING : GDAL should be compiled with thread support for safe execution > > in Java." > > > > But I am not getting it. So the error must be coming from loading > > "gdalconstjni.dll" or "osrjni.dll" but not "gdaljni.dll" or "ogrjni.dll" > > > > I haven't tried that with Linux but I will. > > > > I search for "java.lang.UnsatisfiedLinkError: > > org.gdal.gdal.gdalJNI.HasThreadSupport()I" on the web there are a hand > > full of question about that but none of the suggestions mentioned the JRE > > vs JDK issue. > > > > Does anybody has a clue? > > I'm a bit skeptical about this being a JRE vs JDK issue. I suspect that you > have an issue with the supporting dll (the 4 jni ones and gdalXXX.dll and its > dependencies) not being found in the PATH. You are right. But if one of the GDAL/OGR JNI DLL was missing, the message would be something like: java.lang.UnsatisfiedLinkError: no gdaljni in java.library.path Exception in thread "main" java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI .AllRegister()V at org.gdal.gdal.gdalJNI.AllRegister(Native Method) at org.gdal.gdal.gdal.AllRegister(gdal.java:475) The problem seems to be the dependencies. Looking at he Process Monitor I can see that there is a lot of confusion going on between 64 and 32 bits versions of third level DLLs (GDAL -> plugin -> SDK-X -> etc. -> etc.). It is a Windows 7 64 bits machine. All I need to do is to complete isolate the PATH on my script from whatever is on the system PATH by *not* using %PATH% at all. Not either before or *after* the paths I need! Yes, not even after. That WOW64 is very strange. > > I've just tried with an older release-1500-dev.zip from Tamas site and a JRE. > > I put gdalinfo.class (compiled from the samples in swig/java/apps) in C: > \release-1500-dev\release-1500\bin\gdal\java > > And then, after calling SDKShell.bat, just run from there : > > C:\release-1500-dev\release-1500\bin\gdal\java>java -cp gdal.jar;. gdalinfo > > Seems to work. Thank you so very much for doing that test. Best regards, Ivan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
