[gdal-dev] gdal 1.8 tiff

[Even Rouault]

Le mardi 17 mai 2011 16:47:26, Julien Malik a écrit :
> Hello Even,
> 
> My apologies for the late reply.
> 
> I took the quick and not-so-dirty way : gdal is repackaged in the OTB
> ppas, where I have applied the last strategy you mention : I let the
> warning about libtiff version mismatch be emitted, but still register
> the driver.
> Everything is back to normal with this, and the patch is not very
> intrusive.
> 
> Hopefully this will be only temporary, waiting for this "versioned
> symbols" solution from the Debian folks, and I will be able to throw
> away our specific gdal package soon.

Just to follow on that topic : I've applied in 
http://trac.osgeo.org/gdal/ticket/4101 the fix I mentionned before : just emit 
a warning if version mismatch detected and go on loading the GTiff driver.

> 
> Thanks,
> Julien
> 
> Le 11/05/2011 20:03, Even Rouault a écrit :
> > Le mercredi 11 mai 2011 18:51:07, Julien Malik a écrit :
> >> Hello list,
> >> 
> >> I had a bad surprise today using the new gdal 1.8 package available in
> >> ubuntugis-unstable :
> >> 
> >> When linked both to tiff v3 and gdal 1.8, the GTIFF driver is disabled
> >> 
> >> with a warning appearing like :
> >>      WARNING ! libtiff version mismatch : You're linking against libtiff
> >> 
> >> 3.X but GDAL has been compiled against libtiff>= 4.0.0
> >> 
> >> I understand from frmts/gtiff/geotiff.cpp that this is voluntary (though
> >> the warning does not say it actually disables the GTiff driver).
> > 
> > I'm a bit frustrated... I put this check to avoid bug reports actually
> > ;-) Too many people get hurt because of a version mismatch and have a
> > hard tried figuring what goes wrong.
> > 
> >> In my case (building the Orfeo Toolbox library, which has a dependency
> >> needing TIFF and GeoTiff, but not gdal), it has the undesirable
> >> consequence of breaking TIFF support for our ubuntu packages based on
> >> the ubuntugis-unstable ppa
> >> (https://launchpad.net/~otb/+archive/orfeotoolbox-nightly and
> >> https://launchpad.net/~otb/+archive/orfeotoolbox-stable-ubuntugis).
> >> 
> >> The issue has already been discussed on this list, but just to recall :
> >> we had a solution providing usable executables with TIFF support, even
> >> though they were linked to the system libtiff and libgeotiff (it
> >> involved ensuring the proper link order between '-lgdal' and
> >> '-lgeotiff').
> >> 
> >> That's why I think disabling the driver completely is a little hard.
> >> In my case it represents a major regression, and I don't have a lot of
> >> ideas to work around it...
> >> 
> >> 
> >> Is it possible to *not* disable the driver, and keep the warning ?
> > 
> > If your question is "without changing the code ?", the answer is no.
> > 
> > If Debian/Ubuntu goes into the way of using versionned symbols, they can
> > just apply a local trivial patch to disable this check. My rationale is
> > that people that want to mix both libtiff 3 and libtiff 4 are considered
> > to be sufficient advanced users to make patches to undo the sanity
> > checks if they really know what they are doing. IMHO, the default should
> > be to stick to safe settings.
> > 
> > But perhaps I did go too far and I'm open to suggestions. Changing the
> > behaviour of this check is trivial. The difficult part is to figure out
> > the expected behaviour and I just don't know what would be the option
> > that would satisfy most/all people. One possibility would be to disable
> > the driver unless an environment variable
> > GDAL_ACCEPT_MIXED_LIBTIFF_VERSIONS is defined  ?? But that seems to a
> > bit too convoluted. Or just emit the warning and still enables the
> > driver, considering that the warning is enough and that if people get
> > crashes, they would know why. I'm interested by opinion from other
> > people.
> > 
> > Best regards,
> > 
> > Even
> > 
> >> Regards,
> >> Julien
> >> 
> >> NB: I filed a ticket in our bug tracker
> >> (http://bugs.orfeo-toolbox.org/view.php?id=296), feel free to leave
> >> comments there.
> >> 
> >> 
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev