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

Even Rouault even.rouault at mines-paris.org
Tue Oct 18 13:16:20 EDT 2011


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

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


More information about the gdal-dev mailing list