Hey all, QUICK VERSION: When I build the java bindings for gdal, what native dependencies do I need to transfer over to another machine (with an identical install location) to get them to run?
LONG VERSION: I'm working on an application that requires the java bindings for gdal 1.8.0 to be packaged up with the app, along with the native libraries. Now! I've actually accomplished this on Mac OS X -- rather than building from source on each machine, I was able to pull the macports version of gdal using sudo port install gdal +hdf4 +universal then build from source, with --prefix=/opt/local, or the location of that macports variant. Once the bindings had the proper location, I was able to bundle them up inside my jar file and distribute them to other machines. (As long as the *.dylib files are on java's library path, all is well.) My issue is, I'm having a bit of trouble doing the same thing with linux. I've installed gdal-bin with sudo apt-get gdal-bin And can verify that gdalinfo works, for one of the HDF files I need to process. Good news there. I then built the java bindings from source using ./configure --prefix=/usr --with-threads --disable-netcdf --disable-fortran --with-hdf4=/usr make cd swig/java make (After modifiying swig/java/java.opt to point to my native java install.) To make these bindings work on some other machine, I know that I need the four *.so files -- after I run "make" inside gdal/swig/java, though, I end up with three versions of each file: libgdalconstjni.so libgdalconstjni.so.1.15.0 libgdalconstjni.so.1 etc. Now, it looks like the first two (.so and .so.1.15.0) are symlinked to the *.so.1 file -- if I try to bundle either of these and run my project on a fresh machine (without the built source, but after running "sudo apt-get gdal-bin") and use them, I get java.lang.UnsatisfiedLinkError: /root/forma-hadoop/lib/native/libgdaljni.so: libgdal.so.1: cannot open shared object file: No such file or directory I'm stuck, here. I don't know what libgdal.so.1 is, or where it sits. Do I need to bundle this up as well? More generally, what files do the bindings depend on to actually link to the gdal binaries? (My final step, hopefully the working step, is to bundle up the (*.so.1) files, clean, and try again. This worked with OS X, but on OS X I never saw a reference to "libgdal", without the jni extension.) Sorry for such a long email. I plan on doing a blog post detailing all of this work, and putting the final jar file, with OS X and linux dependencies for 1.8, up in a maven repository after this all works out. Best, Sam
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
