Hi Even,
Quoting Even Rouault <even.roua...@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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
