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

[Even Rouault]

Le vendredi 25 février 2011 21:02:06, Sam Ritchie a écrit :
> Even,
> 
> Thanks for the response, and sorry for my late reply, here.
> 
> What you write makes sense, especially after processing this problem a bit
> further. As you mentioned, libgdal1-XXXX was installed by apt-get... the
> problem here is that apt-get has libgdal1-1.5.0, and I was building java
> bindings for 1.8.0.

Yes, Java bindings for 1.8.0 require GDAL 1.8.0 lib.

> 
> What would it take to upgrade these packages? The issue for my workflow now
> is that I need access to 1.8.0, so I'll currently have to keep a custom
> AMI, with gdal built from source. I'd be happy to do the work to upgrade
> these packages to 1.8.0. Any thoughts?

Well, there's the UbuntuGIS PPA that ships with GDAL 1.7.3. I guess that they 
will end up updating to 1.8.0 in some time. You could ask to the osgeo 
'ubuntu' list what their plan is.

If you want to be your own master and not depend on distro packages, you could 
also follow the cookbook made by Frank Warmerdam to build the latest FWTools 
3.0.X for Linux and add Java bindings support in it. See the "How FWTools is 
Built" section in http://fwtools.maptools.org/linux-experimental.html

> 
> Best,
> Sam
> 
> On Thu, Feb 24, 2011 at 1:56 PM, Even Rouault
> 
> <even.rouault at mines-paris.org>wrote:
> > 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