Add capability to safely link against an external libtiff (3.X) and a GDAL build with internal libtiff (4.0) support
|Reported by:||Even Rouault||Owned by:||Even Rouault|
|Severity:||normal||Keywords:||libtiff libgeotiff internal|
Description (last modified by )
Currently it is not safe for an application to link libgdal built with internal libtiff support with system libtiff (3.X), because of the difference of ABI. The same issue could potentially happen with libgeotiff (in 1.9.0dev trunk, it's at v1.3.0, whereas in the wild you mostly find it at v1.2.0).
The solution implemented consists in :
- compiling a libtiff.so/libgeotiff.so,
- extracting the symbols from the .so with objdump,
- and creating a header file that does #define original_symbol_name gdal_original_symbol_name for each symbol.
This process is automated by a dump_symbols.sh scripts in frmts/gtiff/libtiff and frmts/gtiff/libgeotiff that must be run whenever internal libtiff/libgeotiff is updated (and that the version includes new symbols). The generated files are placed in svn to avoid running the script at each build, mainly because the script might only work on Linux. Wouldn't work as it on MacOS. But the end-result should be portable.
Of course, one also must make sure this header file is included at the appropriate places. This mainly consists in including it in the tif_config.h and geo_config.h, but also in the INGR, NITF, JPEG drivers happen to use libtiff symbols, and MrSID for libgeotiff.
The renaming of the symbols is enabled if --with-rename-internal-libtiff-symbols is defined. (--with-rename-internal-libgeotiff-symbols for geotiff).
This can be combined with the --with-hide-internal-symbols of course so that those gdal_ prefixed symbols are not exported, but this is an orthogonal issue.