Hello Even,
Thank you for your answer.
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.
OK, I see your point. It works at link time, but not at "load time"...
Too bad !
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.
No I'm not sure, I didn't test.
So in fact the problem does not come really from hide-internal-symbols,
but from the simple fact that geotiff is included in gdal with a different .
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.
This is the procedure I know as "mangling".
I know Insight Toolkit does that (http://www.itk.org) for the internal
libtiff version, but there are probably some modifications in the
libtiff code.
If this is not an option for you, then I think we're stuck.
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.
I don't know about it neither, but I can imagine what "versioned
symbols" can mean.
But it does not solve my problem (I want to use the packaged version of
gdal in Debian and Ubuntu...)
Thanks,
Julien
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/[email protected]/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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
