[gdal-dev] building against external tiff/geotiff sources ?

[Simon Eves]

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 for
everything, and it seems to work, but this thread now has me worried that
we might be missing functionality.


On Sat, Mar 4, 2023 at 6:40 AM Greg Troxel <gdt at lexort.com> wrote:

> Sebastiaan Couwenberg <sebastic at xs4all.nl> 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..
> >
> > The Debian package will keep using the external tiff because we don't
> > want to deal with the tiff security updates in the embedded copy.
> >
> > Features that are only available when using the embedded copy won't be
> > enabled in the Debian package.
> >
> > The only sane way forward is to not use private functions of tiff.
>
> With s/Debian/pkgsrc/, +1.
>
> The right fix is that if gdal needs private APIs, to add public APIs in
> tiff.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230304/604daab4/attachment.htm>