[gdal-dev] geotiff conflict

MALIK Julien julien.malik at c-s.fr
Tue Apr 26 15:27:52 EDT 2011


Hi Even,


Quoting Even Rouault <even.rouault at mines-paris.org>:

> 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 ?
>

All this comes from the fact that Orfeo Toolbox has ossim as one of  
its main dependency, and ossim handles TIFF via libgeotiff and not via  
gdal.
For example :
http://trac.osgeo.org/ossim/browser/trunk/ossim/src/ossim/support_data/ossimGeoTiff.cpp
which makes extensive use of the geotiff API.
Other TIFF/GeoTIFF related files are :
imaging/ossimTiffOverviewBuilder.cpp
imaging/ossimTiffWriter.cpp
imaging/ossimTiffTileSource.cpp


>>
>>
>> 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

I'm not sure this is an option. Any GIS/remote sensing user dealing  
with TIFF files want bigtiff support I think.

> - or make libtiff 4.X the system libtiff version (as in debian experimental)

OK. What prevents from it ? Is it API/ABI incompatible with previous  
versions ?
For example, could libtiff 4.X be packaged in ubuntugis repository and  
not break other packages ?


>
>> 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.

Sadly, I think it involves modification of libtiff sources.


>
> 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.

This crazy idea came to my mind also : a configure option which would  
allow prefixing all symbols exported by libtiff and libgeotiff.
But this means 2 projects to modify. Surely harder to achieve than  
other solution.

>
>> 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
>
>

Thanks a lot for your comments,
Julien





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the gdal-dev mailing list