Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#3695 closed defect (fixed)

GDAL requires libtiff >= 4.0 to operate

Reported by: dron Owned by: warmerdam
Priority: normal Milestone:
Component: ConfigBuild Version: unspecified
Severity: normal Keywords: libtiff


GDAL cannot pass its test suite when being built against the libtiff 3.9.x. There are multiple changes in 4.0 branch were not ported back in 3.9, including improvements in JPEG codec and likely many other fixes in various other parts of libtiff. There are three ways to fix it: 1. Port everything missed in 3.9 branch. 2. Document the problems user may experience during runtime when using libtiff 3.9. 3. Make the 4.0 branch to be a requirement for external libtiff. The simplest way is the third one. The patch attached adds configure test for libtiff >= 4.0.

Attachments (1)

configure-libtiff-4.0.diff (2.1 KB ) - added by dron 14 years ago.
Configure test for libtiff >= 4.0

Download all attachments as: .zip

Change History (8)

by dron, 14 years ago

Attachment: configure-libtiff-4.0.diff added

Configure test for libtiff >= 4.0

comment:1 by Even Rouault, 14 years ago

I don't think requiring libtiff 4.0 is a good idea since it hasn't been yet released, and even if it was, there are many users that will be bound with libtiff 3.X for still quite a few years (libtiff 4.0beta is only in Debian experimental for now AFAIK). There are indeed a few tests that fail with libtiff 3.X, but I'd consider them to be more corner cases that wouldn't affect most users. Read-only cases will generally work. The difficult cases are things like writing JPEG-compressed overviews while reading existing directories. Perhaps the documentation should state that libtiff 4.0 is the recommended version.

in reply to:  1 comment:2 by dron, 14 years ago

But there is an internal libtiff that could be used as a fallback if the external one is not up-to-date enough (and it is used by many users especially on Windows systems, Debian GDAL package uses it too). I do not see a reason to use an external libtiff if it doesn't provide the full functionality.

comment:3 by warmerdam, 14 years ago

I understand that GDAL is not as safe and fully featured with libtiff 3.9, but I see no reason to prevent building with it if someone wants to. I am *not* in favor of requiring libtiff4+.

comment:4 by dron, 14 years ago

If user has libtiff development package installed then GDAL picks up an external library automatically, after that user tries to pass through the test suite where GDAL aborts. Maybe we can add a >=4.0 test for the case of libtiff autodetection only? Then user still have an option to force GDAL to be built with older libtiff explicitly with the configure script parameter.

comment:5 by warmerdam, 14 years ago

Yes, that seems quite reasonable.

the internal libtiff4 should be used in preference to system libtiff3 by default.

comment:6 by dron, 14 years ago

Resolution: fixed
Status: newclosed

Fixed in r20112.

comment:7 by Even Rouault, 14 years ago

For the record, I've made 2 fixes in r20143 and r20145 that fix regressions observed with JPEG-compressed TIFF and libtiff 3.X

Note: See TracTickets for help on using tickets.