[gdal-dev] geotiff conflict

Tue Apr 26 12:36:45 EDT 2011

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