Difference between revisions of "Link conflicts"

From OTBWiki
Jump to: navigation, search
m (Reverted edits by Ulofyvy (Talk); changed back to last version by Waexu)
Line 1: Line 1:
 
This page tries to give a sum up of the various link conflicts showing up during Orfeo ToolBox compilation.
 
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 ===
+
=== 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 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:
Line 13: Line 13:
 
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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733 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.
 
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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733 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.
  
----
 
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
 
----
 
>=[http://uwireli.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
 
----
 
 
----
 
<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
 
----
 
=[http://ywevysafyfu.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=
 
----
 
=[http://ywevysafyfu.co.cc CLICK HERE]=
 
----
 
</div>
 
 
=[http://uwireli.co.cc CLICK HERE]=
 
----
 
</div>
 
  
 
=== Ossim internal/external ===
 
=== Ossim internal/external ===

Revision as of 18:28, 19 November 2010

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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558733 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.

application essay