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