[gdal-dev] geotiff conflict

[Even Rouault]

Le mardi 26 avril 2011 18:36:45, Julien Malik a écrit :
> Hello,
> 
> As it seems like the gdal 1.8 debian package is not out yet, maybe there
> is still some time left to tackle this issue for the next gdal debian
> package.
> 
> To sum up the current situation when reading TIFF files with gdal :
> - this program :
> http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestGDALOpen.cxx
> segfaults on Debian when linked with "-lgeotiff -lgdal" but not when
> linked with "-lgdal -lgeotiff". It runs fine on Ubuntu
> - this program :
> http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx
> segfaults on Ubuntu when linked with "-lgdal -lgeotiff -ltiff" but runs
> fine when geotiff comes before gdal.
> 
> For now, we managed to provide binary packages for the Orfeo Toolbox
> applications on Ubuntu by ensuring geotiff comes before gdal in the link
> list (see https://launchpad.net/~otb). This works because we manage the
> build from begining to end.
> 
> But this is a showstopper for our efforts to provide QGis plugins based
> on Orfeo Toolbox : even with the (fragile) solution we ended up with
> (ensuring the order geotiff-gdal in all our link commands), our qgis
> plugins crash as soon as they read a TIFF file on Ubuntu.
> So we are stuck and cannot release binaries of those plugins.

Stupid question (that won't solve the root cause of the problem): why do you 
need direct access to libtiff and libgeotiff ? Can't you do what you need to do 
with the GDAL GTiff driver ?

> 
> 
> What can we do to help find a solution (what kind of modification to the
> gdal debian package would you agree to make to solve this issue) ?

I'm not sure the solution is really in the debian packaging...

There are indeed very few (safe and easy) options :
- build the GDAL package to link with system/external libtiff and libgeotiff. 
But then you loose bigtiff support
- or make libtiff 4.X the system libtiff version (as in debian experimental)

> Do you have pointers on those "versioned symbols" you were referring to ?

Not better that what you can find with a search with your favorite search 
engine...

> Are you still against the redefinition of the internal tiff/geotiff
> symbols or is this an option for you (for libtiff, there is already a
> working solution in the InsightToolkit) ? It seems to be the safest
> solution to me.

I haven't watched what InsightToolkit does. Do you have some info ?

If you can come with a solution that doesn't involve modifying the source code 
of libtiff/libgeotiff after it is imported in GDAL source tree, that might be 
worth considering it.

Otherwise if you have a minimum invasive patch that could be upstreamed to the 
libtiff and libgeotiff projects, and conditionnaly enabled with some #ifdef that 
could be turned on when included in GDAL, that could perhaps be a viable 
solution. Provided that libtiff/libgeotiff mainteners are OK with that.

> Are we still the only people on Earth linking programs with both gdal
> and geotiff ;) ?

Eh eh, I'd say "yes", just so that it becomes a motivation for you to come 
with patch(es) ;-) That's how FOSS evolves...

Best regards,

Even