Hello,
As it seems like the gdal 1.8 debian package is not out yet, maybe there
is still some time left to tackle this issue for the next gdal debian
package.
To sum up the current situation when reading TIFF files with gdal :
- this program :
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestGDALOpen.cxx
segfaults on Debian when linked with "-lgeotiff -lgdal" but not when
linked with "-lgdal -lgeotiff". It runs fine on Ubuntu
- this program :
http://hg.orfeo-toolbox.org/OTB/file/1e0e2f87aa59/CMake/TestXTIFFOpen.cxx segfaults
on Ubuntu when linked with "-lgdal -lgeotiff -ltiff" but runs fine when
geotiff comes before gdal.
For now, we managed to provide binary packages for the Orfeo Toolbox
applications on Ubuntu by ensuring geotiff comes before gdal in the link
list (see https://launchpad.net/~otb). This works because we manage the
build from begining to end.
But this is a showstopper for our efforts to provide QGis plugins based
on Orfeo Toolbox : even with the (fragile) solution we ended up with
(ensuring the order geotiff-gdal in all our link commands), our qgis
plugins crash as soon as they read a TIFF file on Ubuntu.
So we are stuck and cannot release binaries of those plugins.
What can we do to help find a solution (what kind of modification to the
gdal debian package would you agree to make to solve this issue) ?
Do you have pointers on those "versioned symbols" you were referring to ?
Are you still against the redefinition of the internal tiff/geotiff
symbols or is this an option for you (for libtiff, there is already a
working solution in the InsightToolkit) ? It seems to be the safest
solution to me.
Are we still the only people on Earth linking programs with both gdal
and geotiff ;) ?
Regards,
Julien
Le 29/11/2010 17:08, Julien Malik a écrit :
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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
