Here's RC3 with the fix for the issue Kurt raised (and a few relatted
formatting printf() tidy up):
- https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.gz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.gz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.xz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc3.tar.xz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc3.zip
- https://download.osgeo.org/libtiff/tiff-4.5.0rc3.zip.sig
Le 13/12/2022 à 21:39, Even Rouault a écrit :
Hi,
The changes in IFD loop detection are non-trivial enough to justify a
rc2, so here it is:
- https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.gz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz
- https://download.osgeo.org/libtiff/tiff-4.5.0rc2.tar.xz.sig
- https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip
- https://download.osgeo.org/libtiff/tiff-4.5.0rc2.zip.sig
Hopefully this will be the final release candidate for 4.5.0. Please
test and report.
The changes since rc1 are:
- restore formatting of tiffvers.h so that FindTIFF.cmake can infer
libtiff version number
- addition of TIFFLIB_MAJOR_VERSION, TIFFLIB_MINOR_VERSION,
TIFFLIB_MICRO_VERSION in tiffvers.h
- introduction of TIFFLIB_AT_LEAST(major, minor, micro) macro in
tiffvers.h
- CMake: restore BUILD_SHARED_LIBS=ON default setting for top-level
builds
- IFD loop detection: changed algorithm to use a hashset/hashmap for
good performance
- tdir_t type updated to uint32_t. This type is now used for the
return value of TIFFCurrentDirectory and TIFFNumberOfDirectories, and
as the argument of TIFFSetDirectory and TIFFUnlinkDirectory
- Increase the maximum number of IFDs that libtiff can browse through
from 65535 to 1048576. This value is a build-time setting, available
in tif_config.h, that can be configured with CMake's
TIFF_MAX_DIR_COUNT and variable or autoconf's --with-max-dir-count
option.
- tiffinfo: support more than 64k IFDs.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
