[gdal-dev] Backporting rename-internal-libtiff-symbols to GDAL 1.8.0 ubuntu package ?

[Julien Malik]

Hi Even,

Le 18/10/2011 19:16, Even Rouault a écrit :
>> Therefore, my plan is to provide, in our PPA ([3], [4]), yet-another
>> patched GDAL 1.8.0 package integrating this fix, and building gdal with
>> --with-rename-internal-libtiff-symbols=yes and
>> --with-rename-internal-libgeotiff-symbols=yes
>> I think applying and using the "rename-internal-libtiff-symbols" patch
>> will create an ABI compatible GDAL library (the ultimate goal is of
>> course to provide a package which is ABI-compatible with all the
>> packages of ubuntugis-unstable).
>>
>> I would appreciate the opinion of GDAL developers and Ubuntu/Debian
>> package maintainers about this assumption I'm making.
>> Do you see an issue that I would have missed ?
> My initial thought without checking :
> I don't think it should cause any ABI problem. IMHO, the symbols of the
> internal libtiff and libgeotiff have never been thought as belonging to the GDAL
> API/ABI. I believe that Debian uses --with-hide-internal-symbols by the way
> (to be confirmed by the package mainteners of course), so those symbols were
> already not available to binaries linking to GDAL.
>
> But...
> I've just done a test and the results are mixed. It appears that the internal
> libtiff symbols are not exported as expected when using  --with-hide-internal-
> symbol, but the libgeotiff ones are exported ... So, there could be issues if
> --with-rename-internal-libgeotiff-symbols is used and an external binary linked
> to GDAL hoping that it would export the libgeotiff symbols.

Seems coherent with what I know about this issue (on Ubuntu platforms).
The symbol problem results for us in segfaults in libtiff, after 
initializing the TIFF header by the geotiff symbol XTIFFOpen.
So it's the geotiff symbol from GDAL that is used.

But with-hide-internal-symbol has the effect of making it impossible to 
link objects needing geotiff symbols by only linking to GDAL (the 
problem appear later, at runtime).

So that external binary would have had to link explicitely to the "real" 
geotiff library at some point.


> Side node : I don't understand why Debian/Ubuntu uses internal libgeotiff, and
> not external libgeotiff ? I don't see a good reason for that.
>
> My conclusion :
> If you want to apply the patch and be on the safe side, you have to review all
> libs/apps that link to libgdal and check if they use libgeotiff symbols
> (symbols beginning by GTIF). If they link to both libgdal and (external)
> libgeotiff, then the patch should be OK. If they link only to libgdal, then
> there's an issue. And even if there's no problem with packaged applications,
> there's still the possibility of non-packaged ones depending on that...

Thanks for the input.
So for the moment I conclude it's worth working on it, I understand I'm 
on the safe side.


Julien