[gdal-dev] Problems with TIFF internal symbols

[Emmanuel Christophe]

Hi,
I took a bit more time to investigate this and came out with a minimal
test case to reproduce that (using only gdal). The context is a
project using gdal AND some specific geotiff methods thus requiring
both for linking.

Since gdal 1.6 on Debian, the option with-hide-internal-symbols is
used which appears to cause segmentation fault when reading geotiff
files.

The test program (also attached):

#include "gdal.h"
int main(int argc, char * argv[])
{
  GDALAllRegister();
  GDALOpen(argv[1], GA_ReadOnly );
}

It is compiled using cmake with the following CMakeLists.txt:

FIND_PATH(GDAL_INCLUDE_DIR gdal.h /usr/include/gdal)
FIND_LIBRARY(GDAL_LIBRARY NAMES gdal)
FIND_LIBRARY(TIFF_LIBRARY NAMES tiff)
FIND_LIBRARY(GEOTIFF_LIBRARY NAMES geotiff)

INCLUDE_DIRECTORIES(${GDAL_INCLUDE_DIR})

ADD_EXECUTABLE(gdalHideSymbols gdalHideSymbols.cxx)
TARGET_LINK_LIBRARIES(gdalHideSymbols ${TIFF_LIBRARY}
${GEOTIFF_LIBRARY}  ${GDAL_LIBRARY})

I'm trying that using an updated debian testing with the official
packages for tiff, geotiff, gdal. Just 'cmake .', then 'make'

The segfault can be reproduced using a geotiff image, for example:
http://hg.orfeo-toolbox.org/OTB-Data/raw-file/51234ada686c/Input/ROI_QB_MUL_4.tif

It doesn't happen when the link to the geotiff library is removed.

Emmanuel


On Mon, Sep 21, 2009 at 4:45 PM, Francesco P. Lovergine
<frankie at debian.org> wrote:
> On Fri, Sep 18, 2009 at 08:55:03AM +0200, Antonio Valentino wrote:
>> Hi list,
>> I'm trying to use OTB (Orfeo ToolBox) on Debian Sid with GDAL 1.6.2 and
>> I get a lot of segmentation fault related to GDAL and TIFF files.
>>
>> A guy on the OTB mailing list suggested that it could depend on the
>> "with-hide-internal-symbols" flag used for Debian packages.
>>
>> See thread
>>
>> http groups dot google dot com /group/otb-users/browse_thread/thread/be8ad5e263aafe14
>>
>> (sorry the spam filter of my ISP keeps blocking this message)
>>
>> Is the above hypothesis correct?
>> How can we solve the issue in this case?
>>
>>
>> Best regards
>>
>
> The only problem found in the past with that option was:
>
> http://svn.debian.org/viewsvn/pkg-grass/packages/gdal/trunk/debian/patches/cpl_dll.dpatch?revision=2232&view=markup
>
> and it was detected at linking time. It seems OTB is misusing the original TIFF API or exploting
> some inner problems of the same library. Note that
> the geotiff internal gdal library has been used since 1.6.0 in debian, the old one used the same
> library you are now linking with the default configuration. So the objection seems pointless.
>
> --
> Francesco P. Lovergine
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
FIND_PATH(GDAL_INCLUDE_DIR gdal.h /usr/include/gdal)
FIND_LIBRARY(GDAL_LIBRARY NAMES gdal)
FIND_LIBRARY(TIFF_LIBRARY NAMES tiff)
FIND_LIBRARY(GEOTIFF_LIBRARY NAMES geotiff)

INCLUDE_DIRECTORIES(${GDAL_INCLUDE_DIR})

ADD_EXECUTABLE(gdalHideSymbols gdalHideSymbols.cxx)
TARGET_LINK_LIBRARIES(gdalHideSymbols ${TIFF_LIBRARY} ${GEOTIFF_LIBRARY}  ${GDAL_LIBRARY})
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdalHideSymbols.cxx
Type: text/x-c++src
Size: 112 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20091120/4dd8cce7/gdalHideSymbols.bin