Even,<div><br></div><div>Thanks for the response, and sorry for my late reply, here.</div><div><br></div><div>What you write makes sense, especially after processing this problem a bit further. As you mentioned, <meta charset="utf-8">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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>Best,</div><div>Sam<br><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 1:56 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">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 jeudi 24 février 2011 16:51:12, Sam Ritchie a écrit :<br>
<div><div></div><div>> Hey all,<br>
><br>
> QUICK VERSION:<br>
> When I build the java bindings for gdal, what native dependencies do I need<br>
> to transfer over to another machine (with an identical install location) to<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 building<br>
> from source on each machine, I was able to pull the macports version of<br>
> gdal using<br>
><br>
> sudo port install gdal +hdf4 +universal<br>
><br>
> then build from source, with --prefix=/opt/local, or the location of that<br>
> macports variant. Once the bindings had the proper location, I was able to<br>
> bundle them up inside my jar file and distribute them to other machines.<br>
> (As long as the *.dylib files are on java's library path, all is well.)<br>
><br>
> My issue is, I'm having a bit of trouble doing the same thing with linux.<br>
> 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 --disable-fortran<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 install.)<br>
><br>
> To make these bindings work on some other machine, I know that I need the<br>
> four *.so files -- after I run "make" inside gdal/swig/java, though, I end<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 the<br>
> *.so.1 file -- if I try to bundle either of these and run my project on a<br>
> fresh machine (without the built source, but after running "sudo apt-get<br>
> 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>
</div></div>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 (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 the<br>
libgdal1-XXXX (XXXX being the GDAL version of your Debian/Ubuntu install)<br>
package, which is itself a dependency that should be installed when installing<br>
gdal-bin.<br>
<br>
So if I have understood well your process, what you have done should work...<br>
<br>
One way to check is to 'ldd libgdaljni.so' and do what is necessary to remove<br>
any "not found" dependency.<br>
<div><br>
> Do I<br>
> need to bundle this up as well?<br>
<br>
</div>libgdal.so.1 definitely needs to be available for the bindings to work. Then it<br>
depends on the context if you suppose that the user has it installed through<br>
the package manager, or if you must bundle it yourself ala FWTools for Linux.<br>
<div><br>
> More generally, what files do the bindings<br>
> depend on to actually link to the gdal binaries?<br>
<br>
</div>libgdaljni.so, libogrjni.so and etc.. will link to libgdal and its library<br>
dependencies (which depend on the exact GDAL build)<br>
<div><div></div><div><br>
><br>
> (My final step, hopefully the working step, is to bundle up the (*.so.1)<br>
> files, clean, and try again. This worked with OS X, but on OS X I never saw<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 of<br>
> this work, and putting the final jar file, with OS X and linux dependencies<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>