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).<div>
<br></div><div>Thanks, Even, this is great!<br><div><br><div class="gmail_quote">On Fri, Feb 25, 2011 at 3:11 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Le vendredi 25 février 2011 21:02:06, Sam Ritchie a écrit :<br>
<div class="im">> Even,<br>
><br>
> Thanks for the response, and sorry for my late reply, here.<br>
><br>
> What you write makes sense, especially after processing this problem a bit<br>
> further. As you mentioned, libgdal1-XXXX was installed by apt-get... the<br>
> problem here is that apt-get has libgdal1-1.5.0, and I was building java<br>
> bindings for 1.8.0.<br>
<br>
</div>Yes, Java bindings for 1.8.0 require GDAL 1.8.0 lib.<br>
<div class="im"><br>
><br>
> What would it take to upgrade these packages? The issue for my workflow now<br>
> is that I need access to 1.8.0, so I'll currently have to keep a custom<br>
> AMI, with gdal built from source. I'd be happy to do the work to upgrade<br>
> these packages to 1.8.0. Any thoughts?<br>
<br>
</div>Well, there's the UbuntuGIS PPA that ships with GDAL 1.7.3. I guess that they<br>
will end up updating to 1.8.0 in some time. You could ask to the osgeo<br>
'ubuntu' list what their plan is.<br>
<br>
If you want to be your own master and not depend on distro packages, you could<br>
also follow the cookbook made by Frank Warmerdam to build the latest FWTools<br>
3.0.X for Linux and add Java bindings support in it. See the "How FWTools is<br>
Built" section in <a href="http://fwtools.maptools.org/linux-experimental.html" target="_blank">http://fwtools.maptools.org/linux-experimental.html</a><br>
<div><div></div><div class="h5"><br>
><br>
> Best,<br>
> Sam<br>
><br>
> On Thu, Feb 24, 2011 at 1:56 PM, Even Rouault<br>
><br>
> <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>>wrote:<br>
> > Le jeudi 24 février 2011 16:51:12, Sam Ritchie a écrit :<br>
> > > Hey all,<br>
> > ><br>
> > > QUICK VERSION:<br>
> > > When I build the java bindings for gdal, what native dependencies do I<br>
> ><br>
> > need<br>
> ><br>
> > > to transfer over to another machine (with an identical install<br>
> > > location)<br>
> ><br>
> > to<br>
> ><br>
> > > get them to run?<br>
> > ><br>
> > > LONG VERSION:<br>
> > > I'm working on an application that requires the java bindings for gdal<br>
> > > 1.8.0 to be packaged up with the app, along with the native libraries.<br>
> > > Now! I've actually accomplished this on Mac OS X -- rather than<br>
> > > building from source on each machine, I was able to pull the macports<br>
> > > version of gdal using<br>
> > ><br>
> > > sudo port install gdal +hdf4 +universal<br>
> > ><br>
> > > then build from source, with --prefix=/opt/local, or the location of<br>
> > > that macports variant. Once the bindings had the proper location, I<br>
> > > was able<br>
> ><br>
> > to<br>
> ><br>
> > > bundle them up inside my jar file and distribute them to other<br>
> > > machines. (As long as the *.dylib files are on java's library path,<br>
> > > all is well.)<br>
> > ><br>
> > > My issue is, I'm having a bit of trouble doing the same thing with<br>
> > > linux. I've installed gdal-bin with<br>
> > ><br>
> > > sudo apt-get gdal-bin<br>
> > ><br>
> > > And can verify that gdalinfo works, for one of the HDF files I need to<br>
> > > process. Good news there.<br>
> > ><br>
> > > I then built the java bindings from source using<br>
> > ><br>
> > > ./configure --prefix=/usr --with-threads --disable-netcdf<br>
> ><br>
> > --disable-fortran<br>
> ><br>
> > > --with-hdf4=/usr<br>
> > > make<br>
> > > cd swig/java<br>
> > > make<br>
> > ><br>
> > > (After modifiying swig/java/java.opt to point to my native java<br>
> > > install.)<br>
> > ><br>
> > > To make these bindings work on some other machine, I know that I need<br>
> > > the four *.so files -- after I run "make" inside gdal/swig/java,<br>
> > > though, I<br>
> ><br>
> > end<br>
> ><br>
> > > up with three versions of each file:<br>
> > ><br>
> > > libgdalconstjni.so<br>
> > > libgdalconstjni.so.1.15.0<br>
> > > libgdalconstjni.so.1<br>
> > ><br>
> > > etc.<br>
> > ><br>
> > > Now, it looks like the first two (.so and .so.1.15.0) are symlinked to<br>
> ><br>
> > the<br>
> ><br>
> > > *.so.1 file -- if I try to bundle either of these and run my project on<br>
> > > a fresh machine (without the built source, but after running "sudo<br>
> > > apt-get gdal-bin") and use them, I get<br>
> > ><br>
> > > java.lang.UnsatisfiedLinkError:<br>
> > > /root/forma-hadoop/lib/native/libgdaljni.so: libgdal.so.1: cannot open<br>
> > > shared object file: No such file or directory<br>
> > ><br>
> > > I'm stuck, here. I don't know what libgdal.so.1 is<br>
> ><br>
> > well, I thought that would have been pretty obvious ;-). This is the GDAL<br>
> > shared object used by language bindings and gdal command line utilities<br>
> > (and<br>
> > all other programs relying on GDAL).<br>
> ><br>
> > > , or where it sits.<br>
> ><br>
> > You should likely found it in /usr/lib. It should be installed there by<br>
> > the libgdal1-XXXX (XXXX being the GDAL version of your Debian/Ubuntu<br>
> > install) package, which is itself a dependency that should be installed<br>
> > when installing<br>
> > gdal-bin.<br>
> ><br>
> > So if I have understood well your process, what you have done should<br>
> > work...<br>
> ><br>
> > One way to check is to 'ldd libgdaljni.so' and do what is necessary to<br>
> > remove<br>
> > any "not found" dependency.<br>
> ><br>
> > > Do I<br>
> > > need to bundle this up as well?<br>
> ><br>
> > libgdal.so.1 definitely needs to be available for the bindings to work.<br>
> > Then it<br>
> > depends on the context if you suppose that the user has it installed<br>
> > through<br>
> > the package manager, or if you must bundle it yourself ala FWTools for<br>
> > Linux.<br>
> ><br>
> > > More generally, what files do the bindings<br>
> > > depend on to actually link to the gdal binaries?<br>
> ><br>
> > libgdaljni.so, libogrjni.so and etc.. will link to libgdal and its<br>
> > library dependencies (which depend on the exact GDAL build)<br>
> ><br>
> > > (My final step, hopefully the working step, is to bundle up the<br>
> > > (*.so.1) files, clean, and try again. This worked with OS X, but on OS<br>
> > > X I never<br>
> ><br>
> > saw<br>
> ><br>
> > > a reference to "libgdal", without the jni extension.)<br>
> > ><br>
> > > Sorry for such a long email. I plan on doing a blog post detailing all<br>
> > > of this work, and putting the final jar file, with OS X and linux<br>
> ><br>
> > dependencies<br>
> ><br>
> > > for 1.8, up in a maven repository after this all works out.<br>
> > ><br>
> > > Best,<br>
> > > Sam<br>
</div></div></blockquote></div><br></div></div>