[gdal-dev] Building Java Bindings for use with "apt-get gdal-bin"

[Even Rouault]

Le jeudi 24 février 2011 16:51:12, Sam Ritchie a écrit :
> 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

well, I thought that would have been pretty obvious ;-). This is the GDAL 
shared object used by language bindings and gdal command line utilities (and 
all other programs relying on GDAL).

> , or where it sits.

You should likely found it in /usr/lib. It should be installed there by the 
libgdal1-XXXX (XXXX being the GDAL version of your Debian/Ubuntu install) 
package, which is itself a dependency that should be installed when installing 
gdal-bin.

So if I have understood well your process, what you have done should work...

One way to check is to 'ldd libgdaljni.so' and do what is necessary to remove 
any "not found" dependency.

> Do I
> need to bundle this up as well?

libgdal.so.1 definitely needs to be available for the bindings to work. Then it 
depends on the context if you suppose that the user has it installed through 
the package manager, or if you must bundle it yourself ala FWTools for Linux.

> More generally, what files do the bindings
> depend on to actually link to the gdal binaries?

libgdaljni.so, libogrjni.so and etc.. will link to libgdal and its library 
dependencies (which depend on the exact GDAL build)

> 
> (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