1

I'm getting an unsatisfied link error when running gdal.AllRegister() in my java application running on AWS Lambda.

java.lang.UnsatisfiedLinkError: /var/task/lib/libgdaljni.so: libgdal.so: cannot open shared object file: No such file or directory java.lang.UnsatisfiedLinkError: org.gdal.gdal.gdalJNI.AllRegister()V

This indicates to me that the libgdaljni.so file was found, but depends on the libgdal.so file which was not found.

Both of these files exist in the /var/task/lib director which is in the LD_LIBRARY_PATH. Also note that libgdal.so is a symlink to libgdal.so.2 which is in turn a symlink to libgdal.so.2.2.2.

I also have a method that calls out to gdal without the swig bindings (almost like cgi) which succeeds. So I think all the necessary pieces are in place, but there's something missing in the link between libgdaljni.so and libgdal.so.

Does anyone have any experience with this who might be able to help?

0

I too tried including the gdal libs in /var/task/lib and LD_LIBRARY_PATH with little success; in the end resorting to hard coding in each libraries full path.

System.load("/var/task/lib/libproj.so.12");
System.load("/var/task/lib/libnetcdf.so.11");
System.load("/var/task/lib/libproj.so.12");
System.load("/var/task/lib/libgdal.so.20");
System.load("/var/task/lib/libgdaljni.so");
gdal.AllRegister();

Suggest running ldd libgdal.so to print out the complete list of dependencies your gdal build has. Most of these will already be available in the Lambda container, in which case you can ignore (eg; libpthread.so, libjpeg.so, etc), however some may not (eg; libproj.so).

This indicates to me that the libgdaljni.so file was found, but depends on the libgdal.so file which was not found.

That's my understanding.

Both of these files exist in the /var/task/lib director which is in the LD_LIBRARY_PATH. Also note that libgdal.so is a symlink to libgdal.so.2 which is in turn a symlink to libgdal.so.2.2.2.

Symlinks caused a bit of an issue for us. Deployment to Lambda was done by creating a zip, uploading the zip to S3, and then deploying the zip to Lambda. It didn't seem to matter how we created the zip, when deployed to Lambda the symlinks were no longer symlinks but duplicates of the file. This would have been fine, but pushed the bundle size above the maximum permitted by Lambda. Our solution to this was to explicitly load the non-symlink libs (as per the code above), and not include the symlinks at all in the zip deployment. I'm not sure if this is still an issue.

More details in our repo.

  • I tried hard coding the paths like you mentioned, and came across the same error. ldd libgdaljni.so shows a dependency to libgdal.so and shows it in the expected directory. Did you have to do anything with ldconfig to re-cache the libraries or anything like that? – Braden Roseborough Oct 26 '18 at 22:07
  • If the above did not work, then I can really only make a number of suggestions. It did take some effort to get GDAL running on Lambda. Ensure you've built GDAL on the Amazon Linux AMI (its this distro that Lambda instance run on). Include some Java code in your Lambda function to list and return the files list within /var/task/lib/ just to double check these libraries are being deployed to the Lambda 'instance'. The build process we used is described here; note some dependencies were statically linked. – lock Oct 28 '18 at 23:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.