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