GTiff driver cannot be used with libtiff older than 3.9.0 (still beta)

[dron]

It was found that GTiff driver can fail badly (segfault) on some operations when being linked with the external libtiff older that 3.9.0. This is actually libtiff bug which was fixed in upstream.

Proposed solution: always build with internal libtiff when we have an external one older than 3.9.0.

Best regards,
Andrey

[dron]

Patch to check for libtiff 3.9.0 in configure script

[warmerdam]

Andrey,

Can you expand on the problems encountered? I do not what to be this restrictive on the libtiff version. However, my assumption so far has been that problems with older libtiffs only occur in relatively esoteric situations (building overviews, some other update-in-place type operations).

[dron]

Yes, it is related to overviews. In particular test_5 from gcore/mask.py is failed with the segmentation fault. But I don't think it is esoteric. We should either document somewhere that GDAL should be built with libtiff >= 3.9.0 or enforce it in configure. That is important for packagers. How they know that there is a known problem and a known workaround for it?

Also it dosn't introduce any additional restrictions. Using the internal libtiff the one will get exactly the same functionality as with old external one, but less buggy.

[Even Rouault]

If we enforce internal libtiff, then we should also default to --with-hide-internal-symbols (that was introduced in GDAL 1.5.0, and I think the plan was to default on it for 1.6.0 ?), otherwise people that link their app against GDAL and external libtiff (for example if they use both GDAL and GTK, that inderictly pull external libtiff) that could leak to weird situations where symbols are mixed.

[dron]

That is a good point, thanks. I've created a separate ticket (bug #2673) for that.

[warmerdam]

Andrey,

In what way is mask_5 not esoteric? Masks are esoteric! Even overview building is a bit out of the ordinary.

I am not adverse some documentation or communication for packagers that stresses the value of building with the internal libtiff and --with-hide-internal-symbols. I do not think that it ought to be enforced in configure nor do I think hiding internal symbols should be the default behavior.

What we really need is to get libtiff 3.9 and libtiff 4.0 released.

[warmerdam]

I have done some testing with libtiff 3.6.0 and with a few fixes (#2699) it was possible to do normal sorts of operations (gdalinfo, translate, gdaladdo) on GeoTIFF files without apparent problems. I believe that libtiff 3.6.0 should be our minimum requirement, though it might be nice to warn somewhere that using versions older than libtiff 3.9.0 may result in crashes in some relatively unlikely circumstances.

Andrey - please reopen if you find more serious issues.

[dron]

I've created a page about the TIFF issues: http://trac.osgeo.org/gdal/wiki/TIFF. Feel free to edit.