Even,
I am working with Julien on the same project, and you are right about
the --hide-internal-symbols option : if symbols are not hidden, we
recognize that gdal exposes tiff symbols and we manage to deal with this
case by forcing all tiff access to use gdal internal tiff library (we
have to include the headers in gdal sources in order to be sure to have
headers corresponding to symbols, it would be great to have these
headers installed by gdal, but this is another question). And the case
were gdal links with the system tiff/geotiff is working as well (but
without bigtiff support).
The problem is that we are trying to build debian/ubuntu packages, and
to do it we need to link with the system gdal , which is compiled with
--hide-internal-symbols, so we are kind of stuck here ...
I am surprised that this issue has not been reported before, we are for
sure not the only project using both gdal and geotiff ? My bet is that
we are doing something wrong somewhere, but for now we did not come up
with it. Any idea would be very helpful ...
Regards,
Julien
Le 29/11/2010 15:51, Even Rouault a écrit :
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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Julien MICHEL
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
