[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