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

Antonio Valentino antonio.valentino at tiscali.it
Mon Jul 4 16:27:23 EDT 2011


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

-- 
Antonio Valentino


More information about the gdal-dev mailing list