[gdal-dev] Add capability to safely link against an external libtiff (3.X) and a GDAL build with internal libtiff (4.0) support

[Julien Malik]

Hello,

A little late, but I report success in the tests I ran so far.
None of our problematic test cases causes an error anymore.
In the future I should be more reactive, as I have set up a platform 
testing OTB built on top of the gdal trunk, on a nightly basis.

I still have one last test to run for a final confirmation (building the 
OTB QGis plugins, where the crash was inevitable, despite the handling 
of the link order which bypassed the problem for executable). But I'm 
confident from the results of the other tests...

Many thanks for this long-awaited fix !
Julien

PS: Do you think this renaming option could be pushed upstream to 
libtiff and libgeotiff (maybe not as-is) ?
It would save GDAL the burden of maintaining a patch in its internal 
versions, and it would benefit other projects integrating those libs in 
their source. FYI I'm currently working on a similar patch for openjpeg, 
allowing to choose the renaming prefix at configuration time.



Le 04/07/2011 22:27, Antonio Valentino a écrit :
> Hi,
>
> Il 04/07/2011 20:10, Antonio Valentino ha scritto:
>
> [CUT]
>
>>>> My only concern is that I'm not able to reproduce the crash in cases in
>>>> which GDAL is built without symbol renaming.
>>> Hum, did you activate --with-hide-internal-symbols ? I somehow remember that
>>> it paradoxically helped revealing the duplicate symbol issues.
>> Yes, I tested the both "hide internal symbols" and no symbol hiding with:
>>
>> * gdalinfo linked against gdal libtiff libgeotiff
>> * gdalinfo linked against libtiff libgeotiff gdal
>> * a simple test program that just open a tif file with GDAL and TIFF API
>> * gdal_translate linked against libtiff libgeotiff gdal
>>
>> The last test (the one with gdal_translate) also implies writing a TIFF
>> file.
>>
>> None of this tests produced a segfault even if in some cases I get
>> warnings about linking against the wrong libtiff version (one of the
>> changes you applied recently if I remember well).
>>
>> I clearly remember I was on debian when a experimented the problem some
>> time ago even if I don't understand why this should make any difference
>> if I build GDAL with the same compilation flags.
>>
>> I'm going to do some test with Julien's programs tonight.
> In my tests the only program that causes a segfault is
>
> [1] http://hg.orfeo-toolbox.org/OTB/file/tip/CMake/TestXTIFFOpen.cxx
> Linked with '-lgdal -lgeotiff -ltiff' (--with-hide-internal-symbols).
>
>
> The same program works as expected id GDAL is build with
>
> --with-hide-internal-symbols=yes
> --with-rename-internal-libtiff-symbols=yes
> --with-rename-internal-libgeotiff-symbols=yes
>
> IMHO this definitively closes the question.
>
>
> regards
>