1

I'm having some trouble with GDAL and BIGTIFF support. I work on a multi user cluster, and the defaults for GDAL are 1.9.2 there. I've built GDAL 2.1.3, libtiff, libgeotiff, and proj4, making sure to use BIGTIFF support. Everything works fine during the build, and the configure recognizes bigtiff during the GDAL build. All good.

However, when I attempt to use gdal_merge.py, I get the following errors thrown:

<GDALPATH>/bin/gdal_merge.py
Warning 6: Driver GTiff does not support BIGTIFF creation option
Warning 6: BigTIFF requested, but GDAL built without BigTIFF
enabled libtiff, request ignored

I've set my environment variables as:

export PATH=<GDALPATH>/bin:${PATH}
export LD_LIBRARY_PATH=<GDALPATH>/lib
export LD_RUN_PATH=<GDALPATH>/lib
export PYTHONPATH=<GDALPATH>/lib64/python2.6/site-packages

When I run gdal_merge.py --version, I get the correct gdal library, with the version as: 

GDAL 2.1.3, released 2017/20/01

But when I run the actual gdal_merge.py , I get the error listed above. Everything built / installed correctly, but for some reason, despite configuring and building with it, the gdal_merge call won't use BIGTIFF support, almost as if it's still pushing the 1.9.2 system version that does not contain support.

I also ran an strace, and after initially finding it wasn't actually finding the libtiff.so (it was looking for .3 instead of .5), I created a symlink and directed it there. So it's definitely using the custom build libtiff and libgeotiff at runtime.

So, that brings me back to the question. Is there a hidden variable somewhere I'm not aware of getting used? Or is there a way to test for BIGTIFF support after a build besides it failing? I know non-standard installs are always a unique challenge, but nothing I've done so far allows for BIGTIFF use in the merge, and the merges fail at the size of system memory.

Improve this question
6
  • The error states that the problem is not in GDAL but in the libtiff version you have used when you built GDAL: LibTIFF BigTIFF requested, but GDAL built without BigTIFF enabled libtiff. However, you told that you built libtiff with BigTIFF support. Could you have some other libtiff in your system which is picked during GDAL build?
    – user30184
    Commented Mar 15, 2017 at 20:56
  • I did have that issue initially, which I found with strace, but after providing a symlink to the one gdal was looking for (libtiff.so.3) and pointing it to libtiff.so.5, it appears to be properly picking up that library according to the strace output. I also double checked that the correct libgeotiff is getting used, and it is as well. So I'm very confused as to how it's not picking up the BIGTIFF enabled library.
    – Alec Bennett
    Commented Mar 15, 2017 at 20:59
  • To be sure it is a general and not Python-only issue, do you get the same error with gdal_translate -of GTiff -co BIGTIFF=YES foo.tif bar.tif?
    – user30184
    Commented Mar 15, 2017 at 21:10
  • Good call on that. Yes, I'm getting the same issue there, which at least rules python out. And the gdal_translate is using the correct 2.1.3 build of GDAL according to the version. I will dig further from that point of view.
    – Alec Bennett
    Commented Mar 15, 2017 at 21:14
  • Did you rebuild gdal by pointing it to use libtiff.so.5?
    – user30184
    Commented Mar 15, 2017 at 21:18

1 Answer 1

Reset to default
1

Ok, so the problem here was within the build of libgeotiff. The library did not get built properly, and from running "nm libgeotiff.so", it was missing the symbols from GTIFAllocDefn and GTIFFreeDefn.

The geotiff library had, apparently, built against the system installed version due to a mismatch of the library name. So while libtiff built with bigtiff support, libgeotiff did not. But since GDAL was apparently looking at libtiff to say it had BIGTIFF support, but not libgeotiff, it failed to build properly, despite claiming it configured properly.

I can't definitively isolate what happened there to repeat it, but rebuilding libgeotiff followed by gdal seems to have done the trick, and bigtiff support is now working.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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