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

[Sam Ritchie]

A custom build of fwtools sounds like the perfect solution, here. Then my
bootstrap procedure consists of downloading my FWTools build, opening it up,
running ./install.sh and adding the directory to the path (to allow access
to the libraries).

Thanks, Even, this is great!

On Fri, Feb 25, 2011 at 3:11 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110225/47e1725e/attachment-0001.html