#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 |
| Cc: |
Description
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)
Change History (8)
by , 13 years ago
| Attachment: | configure-libtiff-4.0.diff added |
|---|
follow-up: 2 comment:1 by , 13 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.
comment:2 by , 13 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 , 13 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 , 13 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 , 13 years ago
Yes, that seems quite reasonable.
the internal libtiff4 should be used in preference to system libtiff3 by default.
Configure test for libtiff >= 4.0