Opened 13 years ago
Last modified 13 years ago
#4144 closed enhancement
Add capability to safely link against an external libtiff (3.X) and a GDAL build with internal libtiff (4.0) support — at Initial Version
Reported by: | Even Rouault | Owned by: | Even Rouault |
---|---|---|---|
Priority: | normal | Milestone: | 1.9.0 |
Component: | ConfigBuild | Version: | unspecified |
Severity: | normal | Keywords: | libtiff libgeotiff internal |
Cc: |
Description
Currently it is not safe for an application to link libgdal build 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/libgeotiffs.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).
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_ symbols are not exported, but this is an orthogonal issue.