[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