Link conflicts

From OTBWiki
Revision as of 15:48, 27 August 2013 by SebastienDinot (Talk | contribs) (Remove spam)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page tries to give a sum up of the various link conflicts showing up during Orfeo ToolBox compilation.

Tiff and Jpeg symbols inside gdal

Gdal can be compiled with embedded tiff, geotiff and jpeg symbols (--with-tiff=internal). Using such a gdal with OTB was causing link conflicts and segmentation fault because of mainly two issues:

  • Gdal does not provide the headers corresponding to the symbols, so the headers were often coming from another version of the jpeg or tiff library,
  • Some executable or library in OTB were explicitely linking against libtiff libgeotiff or libjpeg in addition to linking to libgdal, causing the same symbol to appear twice (sometimes in different versions).

This problem is solved if gdal AND OTB both use the same tiff, geotiff and jpeg library. Unfortunately, most of OTB users are using the internal tiff from gdal because it is compile with BIGTIFF option which is useful to read some products.

So the solution choosen for now was to check during cmake configuration if gdal exposes tiff, geotiff and jpeg symbols, and to use gdal in place of those library if it does. If not, cmake ask for thoses libraries. As said before, gdal does not provide the tiff, geotiff and jpeg headers as part of the include folder, so in the case where corresponding symbols are exposed, one has to use include from gdal sources (which is quite dirty) to get the appropriate headers.

Specific for debian testing (and probably recent Ubuntu): gdal package after 1.6 is compile with symbol masking (and internal tiff/gtiff) which led to the use of another tiff/geotiff for the rest of the library (the system ones which are incompatible with those included in gdal). It is reported in: one possible solution is to ensure that the link to gdal happens BEFORE gtiff everywhere. Current tentative to modify the OTB configuration to ensure that have been unsuccessful.

Ossim internal/external

For now, OTB can't use an external version of ossim due to the partial migration of SAR sensor models towards ossimplugins. Once the migration is completed, it should be possible to use the vanilla ossim.

Sar model migration to ossim plugins

Only a partial migration is completed as of 2010-01-13. Radarsat1 and Envisat are still NOT handled by the plugins. Due to the interface change in ossim (around nov 2009), they are not handled at all anymore. The plugin structure is better than what was done for the original model and it is not necessary to have an image handler: just the projection handler will do. This simplifies the code but requires some work for the adaptation.