#1920 closed defect (fixed)
GDAL 1.4 and libtiff4 incompatible
| Reported by: | warmerdam | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.4.3 |
| Component: | GDAL_Raster | Version: | 1.4.2 |
| Severity: | normal | Keywords: | gtiff bigtiff |
| Cc: |
Description
It *seems* like gdal from the 1.4 branch will build against libtiff4 (aka the BigTIFF release), but results are subtly wrong. For instance gdalchksum.py results on the file gdalautotest/gcore/data/sstgeo.tif are wrong.
If this can be easily fixed, then that would be good, otherwise we should ensure that gdal 1.4.3 will explicitly fail to build with libtiff4 "explaining" why.
Attachments (1)
Change History (6)
comment:1 by , 17 years ago
by , 17 years ago
| Attachment: | gdal_svn_branch1.4_bug1920.patch added |
|---|
comment:2 by , 17 years ago
Even,
Unfortunately this just papers over subtler incompatibility between GDAL 1.4.x and libtiff4. I believe the solution is to cause the GDAL configure and/or GDAL build to error out if given libtiff4.
comment:3 by , 17 years ago
I've commited in branch 1.4 in r12500 a test in configure.in that prevents building GDAL with libtiff >= 4.0. (the test is taken from configure.in from trunk) Please regenerate configure.
comment:4 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I have confirmed that the patch seems to operate as I would hope. Closing.
(and committing updated configure)
comment:5 by , 16 years ago
Added compile time check in frmts/gtiff/geotiff.cpp (r12564) to confirm we aren't building with libtiff4. This is in case someone uses libtiff4 on windows with GDAL (not caught by configure).
This issue is due to variables of type 'uint32' used in place of 'toff_t' in a few places in geotiff.cpp. The attached patch gives the same checksums for 1.4 branch and trunk. (it's more or less r11744 and r12221 applied to 1.4 branch)