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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
