[gdal-dev] geotiff conflict

[Julien Michel]

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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>    


-- 
Julien MICHEL