[gdal-dev] geotiff conflict

[Julien Malik]

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