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

[Sam Ritchie]

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.

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?

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/b11fc81a/attachment.html