[gdal-dev] geotiff conflict

[Even Rouault]

Julien,

To be fair, I think that --with-hide-internal-symbols just does what it
advertizes : it hides GDAL internal symbols (internal libtiff, internal
libgeotiff) to applications that link with libgdal. I mean that they cannot use
those symbols (if they only link to libgdal). The advantage is that it speed-ups
the loading of the library and the resolving of its symbols.

However, it doesn't do what we could expect : in the case the application links
with several libraries that define the same symbol (exported or not), it has no
influence on how the symbols are resolved by the dynamic linker. So depending on
the linking order of -lgdal -lgeotiff or -lgeotiff or -lgdal, the symbol
resolver will choose either the one from GDAL or the one from libgeotiff.

By the way, are you sure that --with-hide-internal-symbols actually worsens the
situation ? I'd have bet you'd got the same/similar issues with a build that
doesn't use --with-hide-internal-symbols.

I tried recently to use some trickery based on #define for the internal libtiff.
The internal libtiff would have lines (in tif_config.h or in a specific header
file imported by it) which would redefine each symbol like #define TIFFGetField
GDAL_TIFFGetField. This was easily done with a simple script that parsed the
output of nm/objdump -T on libtiff. It mostly worked but I couldn't get to work
it completely without modifying the libtiff files, due to their use of #define
mechanisms inside libtiff in a few places (in tif_swab.c and
tif_jpeg.c/tif_jpeg_12.c). And it isn't reasonable to modify the libtiff files
as they are directly imported from upstream libtiff. So that effort is mostly
stalled for now. As far as using ld versionned symbols as Francesco Lovergine
suggested, I've no experience with that mechanism. Perhaps you could investigate
on that side.

Even

> Hello,
>
> I'm reviving an already known problem about the gdal packages for
> Ubuntu/Debian, related to the use of the hide-internal-symbols configure
> option.
>
> To sum it up, we get into troubles with the gdal packages since we also
> use the geotiff API.
>
> Until recently, we knew only about a problem with Debian. It had been
> reported for example :
> - http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg04966.html
> - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733
>
> A similar issue now appears on Ubuntu.
> Attached are two little tests showing up the problem, with an associated
> CMakeLists.
> test.cxx uses the geotiff and tiff API.
> test2.cxx is the test program reported in the debian bug tracker
>
> both programs are simple executable taking one tiff file as input.
>
> test.cxx produces segfault when the link line has gdal before geotiff,
> and runs ok in the other cases (tiff does not seem involved).
> The segfault appears in the TIFFGetField call, probably because the
> TIFF* returned by XTIFFOpen comes from the gdal internal geotiff
> implementation and not the system geotiff lib, thus returning an
> incompatible pointer.
>
> test2.cxx does not segfault (though it does on Debian systems when gdal
> is before geotiff).
>
> I see the Ubuntu problems on at least two systems :
> - Ubuntu 10.04 with official packages (gdal 1.6.3)
> - Ubuntu 10.10 with gdal package from UbuntuGIS-unstable
>
> There seems to be a bug with the hide-internal-symbols which, well...,
> does not really hide internal symbols.
> Is there a known solution to these problems (apart from hand-made gdal
> recompilation which is not a solution for our end-users) ?
> Has the mangling of the internal tiff/geotiff libs already been studied ?
>
>
> Best regards,
> Julien
>
>
>