[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