If one native library (DLL) loads another, the "java.library.path" variable will not be honored, since it's not Java doing the load, but the OS trying to resolve the dependencies for the DLL. As Daniele suggested, Dependency Walker is a great tool for finding out the relationships between libraries. To solve this problem in software I write, I often do a "defensive load". You can call System.loadLibrary() with the secondary library and have Java load it up from the "java.library.path". Then, when the JNI library is loaded, the library it depends on will already be in memory ready to go. Using this technique I have never had to place native libraries in the JDK itself. This method work only on windows, where DLLs are reused in a process by default, and will most likely not work on other platforms.
-- Ben From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Daniele Romagnoli Sent: Monday, February 23, 2009 6:24 AM To: trailcode Cc: gdal-dev@lists.osgeo.org Subject: Re: [Gdal-dev] GDAL 1.6 Java binding, Windows Hi, please read below. On Mon, Feb 23, 2009 at 12:06 AM, trailcode <trailc...@gmail.com<mailto:trailc...@gmail.com>> wrote: I got gdal java binding to work with win32. I downloaded the jre from: http://udig.refractions.net/files/downloads/jre/ Note that these libraries have been built against GDAL 1.4.4. Where do you have placed the DLLs to let them work during your first test? And used it to execute my test program. For the java .jar files I am not using gdal.jar but the jars which come with: imageio-ext The thing which is strange is if I copy the gdaljni.dll gdal14.dll and other .dll files from the jdk downloaded above to my project dir and set my java.library.path to point to them I get the same old unsatisfied link error. I even tried copying over all .dll files in the JDK tree but got the same message. Does anyone have any idea what is going on here? On Windows, we have sometime noticed similar issues on DLL native libs loading. Not sure what is happening when this occurs. (Be sure that all required libraries are together with these DLLs (A check with "Dependency walker" may be helpful)). A solution could be putting them on your JDK/bin being sure that the same libs aren't somewhere on folders linked by your PATH env. (Be sure you don't have old GDAL Libs somewhere hidden on your machine) This could be helpful to do some initial testings. See my next feeddback about JNLP. I would like to create an application distributable via jnlp. We are working on creating a web start application involving other native libraries (not GDAL related). Therefore we will handle native DLLs loading and some feedbacks on this topic will come in the near future (we are working on it this week). Cheers, Daniele Thanks, Matthew Tang -- View this message in context: http://n2.nabble.com/GDAL-1.6-Java-binding%2C-Windows-tp2299600p2369562.html Sent from the GDAL - Dev mailing list archive at Nabble.com. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ------------------------------------------------------- Eng. Daniele Romagnoli Software Engineer GeoSolutions S.A.S. Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 328 0559267 http://www.geo-solutions.it -------------------------------------------------------
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
