[gdal-dev] GDAL + libtiff
Even Rouault
even.rouault at mines-paris.org
Tue Jan 14 14:54:42 PST 2014
Hi Tamas,
> Hi Devs,
>
> I'm a bit confused what would be the suggested approach of using GDAL with
> the internal libtiff when the application would also use libtiff directly.
> Is GDAL libtiff just the raw copy of the "official" libtiff or just a
> limited functionality has been taken over?
It is a copy of official libtiff (the lib part of course, not the libtiff
utilities) + some configuration to use GDAL configuration ( like enabling JPEG
codec if jpeg is available to GDAL, 64bit integers, etc...)
>
> Actually some of the functions of the library has been exposed by gdal.dll,
> but many of the functions are missing. In this regard we might require to
> use libtiff directly by the application, but the mixture of the versions
> may lead to problems specifically.
Yes, this has been a problem on Linux where internal GDAL was libtiff 4 and
system libtiff 3.8 and 3.9. I ended up providing an option to rename the
symbols of internal libtiff so they cannot collide with external libtiff.
>
> I might also ask this from the aspect of an SDK distribution provider.
> Should I provide the compilation of the standalone libtiff along with gdal
> (compiled as dll or static lib) and which versions should be used? Or we
> should modify the GDAL build process to compile at least the static libtiff
> in addition?
You could compile the latest libtiff 4.0.X (you want 4.something for BigTIFF
support) externally as a dll, and link GDAL against it. So that would please
both people wanting to use libtiff directly and GDAL. I imagine this is how it
is done in OSGeo4W (I haven't verified though).
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
More information about the gdal-dev
mailing list