I've also been looking at this, because we were previously using internal
TIFF and GeoTIFF but also other libraries with their own TIFF, plus another
one that needed TIFF, so we presumably ended up with four linked versions!
I have reworked everything so that we use one external TiFF and GeoTIFF f
Sebastiaan Couwenberg writes:
> On 3/4/23 11:10, Landry Breuil wrote:
>> what do other packagers of gdal think about it ? Providing an
>> option/flavor for end-users of the packaging system to build against
>> internal copies might also be possible, but that creates havoc in
>> dependency trees..
On 3/4/23 11:10, Landry Breuil wrote:
what do other packagers of gdal think about it ? Providing an
option/flavor for end-users of the packaging system to build against
internal copies might also be possible, but that creates havoc in
dependency trees..
The Debian package will keep using the ex
Hi,
currently some interesting features (for example jxl compression in
tiff) requires one to build against internal tiff/geotiff - after
looking at the code, from my understanding this is because the gtiff
driver reaches to internal tiff functions not present in the public API,
which (to me) is a
