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

[Francesco P. Lovergine]

On Tue, Oct 18, 2011 at 07:16:20PM +0200, Even Rouault wrote:
> > 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.
> 

Confirmed. On those regards I would appreciate if you would have a try
in linking by using current experimental gdal 1.8.1 available in the archive.
On the basis of my trials tiff/geotiff/gdal can now be linked together in
whatever order without problems, with that version.

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

The true problem is that we currently are distributing the traditional
non-bigtiff enabled libtiff and people are quite resistant in changing that.
That forces me to use the internal library. Also, at the time of squeeze
release the internal geotiff support was more recent than the official
geotiff. That could be currently different.

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

-- 
Francesco P. Lovergine