Mac issues

From OTBWiki
Revision as of 18:28, 19 November 2010 by WikiSysop (Talk | contribs) (Reverted edits by Ulofyvy (Talk); changed back to last version by Julien.Malik)

Jump to: navigation, search

Dealing with FLTK and GDAL

Since OTB 3.2, you can use OTB with an external FLTK and external GDAL downloaded on Macports

  • You must compile your own fltk. Pay attention produce the same configuration than your wanted OTB (Static/Shared and Release/Debug)
  • According to Leopard, Tiger or other Mac osx, the GDAL provided by macport can not work. You will have to compile your own GDAL , here is an example of the command line to run in the GDAL source.
./configure --prefix=GDAL_BINARY_DIR --with-png=internal --with-png=internal --with-libtiff=internal --with-geotiff=internal
            --with-jpeg=internal --with-libz=internal --with-curl=no --with-gif=internal --with-expat=no

where GDAL_BINARY_DIR is the absolute path to directory where you want GDAL to be compiled. The GDAL variable asked by CMake will have to point those binary and source directories.

CMake Troubles

Architecture Troubles

If that kind of error occurs when you configure the OTB CMake project:

CMake Error: OGR MESSAGE: /opt/local/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: entrant dans le rpertoire  /usr/local/stow-dir/OTB-binary-cyrille/CMake/CMakeFiles/CMakeTmp
/usr/bin/cmake -E cmake_progress_report /usr/local/stow-dir/OTB-binary-cyrille/CMake/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec.dir/TestGDALHasOGR.o
/usr/bin/c++ -O2 -W -arch ppc -arch i386 -arch ppc64 -arch x86_64 -I/opt/local/include -o 
CMakeFiles/cmTryCompileExec.dir/TestGDALHasOGR.o -c
Linking CXX executable cmTryCompileExec
/usr/bin/cmake -P CMakeFiles/cmTryCompileExec.dir/cmake_clean_target.cmake
/usr/bin/c++ -O2 -W -arch ppc -arch i386 -arch ppc64 -arch x86_64 -headerpad_max_install_names -fPIC -arch ppc -arch i386 
-arch ppc64 -arch x86_64 "CMakeFiles/cmTryCompileExec.dir/TestGDALHasOGR.o" -o cmTryCompileExec -L/opt/local/lib -lgdal
ld64 warning: in /opt/local/lib/ld64libgdal.dylib , warningfile is not of required architecture
Undefined symbols for:  in architecture/ optx86_64/:local
 / lib /libgdal.dylib, file is not of required architectureOGRSFDriverRegistrar::Open(char const*, int, OGRSFDriver**)
Undefined symbols for architecture ppc64:
   , referenced from:
     OGRSFDriverRegistrar::Open(char const*, int, OGRSFDriver**),  referenced  from_main:
 in   TestGDALHasOGR.o
 ld64-62.1 failed: symbol(s) not found for    _main  architecture x86_64

You can have problem with the compiled architectures. Two things can be tried:

  • In the CMake variable CMAKE_OSX_ARCHITECTURES, suppress the architecture that causes troubles (in the example ppc64).
  • Try to modify the flags and compile GDAL again :
export CFLAGS="-O2 -W -arch i386 "
export CXXFLAGS="-O2 -W  -arch i386 "
export LDFLAGS=" -arch i386"

Compilation Troubles


The ossimPlugins can bring that kind of compilation errors:

ld: symbol(s) not found
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/Ol/OlTphT4pGySqNMZgdIkiCk++ 
+TI/-Tmp-//ccYpbtga.out (No such file or directory)
make[2]: *** [bin/libotbossimplugins.dylib] Error 1
make[1]: *** [Utilities/otbossimplugins/CMakeFiles/otbossimplugins.dir/ 
all] Error 2
make: *** [all] Error 2

Two solutions:

  1. Disable OssimPlugins compilation. For that, open main CMakeLists.txt file of the OTB/Utilities directory. And supress OssimPlugins compilation replacing the line:
SUBDIRS(otbsvm dxflib InsightJournal otbossim otbossimplugins otb6S tinyXMLlib otbkml otbedison otbsiftfast)
SUBDIRS(otbsvm dxflib InsightJournal otbossim otb6S tinyXMLlib otbkml otbedison otbsiftfast)
  1. The second solution (that may not work every times!!) consists in changing the flags.


Conflict happens when 2 variables have the same name. It provides that kind of error:

Scanning dependencies of target otbopenjpeg
[ 62%] Building C object Utilities/otbopenjpeg/libopenjpeg/CMakeFiles/otbopenjpeg.dir/tcd.o
[ 62%] Building C object Utilities/otbopenjpeg/libopenjpeg/CMakeFiles/otbopenjpeg.dir/bio.o
[ 62%] Building C object Utilities/otbopenjpeg/libopenjpeg/CMakeFiles/otbopenjpeg.dir/cio.o
[ 62%] Building C object Utilities/otbopenjpeg/libopenjpeg/CMakeFiles/otbopenjpeg.dir/dwt.o
/usr/local/stow-dir/OrfeoToolbox-3.0/Utilities/otbopenjpeg/libopenjpeg/dwt.c:75: error: 'gamma' redeclared as different kind of symbol
/usr/include/architecture/i386/math.h:584: error: previous declaration of 'gamma' was here
make[2]: *** [Utilities/otbopenjpeg/libopenjpeg/CMakeFiles/otbopenjpeg.dir/dwt.o] Error 1
make[1]: *** [Utilities/otbopenjpeg/libopenjpeg/CMakeFiles/otbopenjpeg.dir/all] Error 2
make: *** [all] Error 2
  1. In this case, you can just disable the libopenjpeg compilation setting in CMake OTB_USE_OPENJPEG=OFF
  2. Make a local change in 1 of the 2 files. Here replace all gamma occurences in Utilities/otbopenjpeg/libopenjpeg/dwt.c file with another name (my_gamma for example). Try to avoid changing system file like the /usr/include/architecture/i386/math.h (it may produce collateral damages in other applications).

void / GLvoid

A mistake was made in some visualization classes. This mistake can provide this kind of error:

[ 99%] Building CXX object Code/Visu/CMakeFiles/OTBVisu.dir/otbGluPolygonDrawingHelper.o
/usr/local/stow-dir/OrfeoToolbox-3.0/Code/Visu/otbGluPolygonDrawingHelper.cxx: In constructor
/usr/local/stow-dir/OrfeoToolbox-3.0/Code/Visu/otbGluPolygonDrawingHelper.cxx:87: error: invalid conversion from 'void (*)()'
to GLvoid (*)(...)'
/usr/local/stow-dir/OrfeoToolbox-3.0/Code/Visu/otbGluPolygonDrawingHelper.cxx:87: error:   initializing argument 3 of 'void
gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)(...))'

The problem is that the compiler is waiting for a method that returns a GLvoid but has a void return instead. To correct that, chage the return type from void to GLvoid. In our example, you'll need to change the function given as the third argument of the method gluTessCallback:

typedef void (CALLBACK * FunctionPointerType)();
typedef GLvoid (CALLBACK * FunctionPointerType)(...);


OTB uses an internal OpenThread version. If your computer already has its own OpenThread intalled, errors like the following one can appears:

[ 93%] Building CXX object
Linking CXX executable ../../bin/DEMToRainbowExample
ld: library not found for -lOpenThreads
collect2: ld returned 1 exit status
make[2]: *** [bin/DEMToRainbowExample] Error 1
make[1]: *** [Examples/BasicFilters/CMakeFiles/DEMToRainbowExample.dir/all] Error 2
make: *** [all] Error 2

If you have this error AND the CMake OpenThread variables look like:

OPENTHREADS_INCLUDE_DIR: /Library/Frameworks/OpenThreads.framework/Versions/A/Headers
OPENTHREADS_LIBRARY: Library/Frameworks/OpenThreads.framework

In this specific case, tou can try a simple manipulation : empty those variables



By now, OTB Team manage to compile OTB on MacOs in Static-Release configuration. If all the previous manipulations don't save your OTB compilation, check your own configuration looking at your CMake variables:


If one of this two variables differs, change its value and try again...

Compilation on MAC OSX 10.6 Snow Leopard

FLTK issue: Starting with 10.6 (Snow Leopard), OS X does not support Carbon calls from 64bit code anymore. FLTK patch this until they are completely Cocoa compliant by limiting to 32 bit Intel compilation

Problem when using MacPorts : The fltk port is compiled in 32 bit, and the GDAL port is compiled in 64 bit. This combination leads to conflicts when linking OTB.

However, there are solutions if you want to use OTB on Mac OSX 10.6 Snow Leopard:

  • Use OTB without compiling GUI functionalities. You have to compile OTB with the cmake flag OTB_USE_VISU=false to deactivate the compilation of the Visualisation module. As such, you won't enjoy the OTB-Applications nor Monteverdi
  • Compile everything in 32 bit mode. This is done by setting the flag CMAKE_OSX_ARCHITECTURES=i386. This implies that you also compile GDAL in 32 bit mode yourself since the MacPort is available only in 64 bit mode. The following procedure has been reported to work for compilation of OTB, OTB-Applications and Monteverdi on a MacBook (i386 architecture) with a freshly installed 10.6 OS and no MacPort installed at all (be sure to have at least :
export GDAL_SRC_DIR=/path/to/sources/of/gdal-1.6.3
export GDAL_INSTALL_DIR=/path/to/gdal/install

export OTB_SRC_DIR=/path/to/sources/of/OTB
export OTB_BUILD_DIR=/path/to/build/directory/OTB

export MONTEVERDI_SRC_DIR=/path/to/sources/of/Monteverdi
export MONTEVERDI_BUILD_DIR=/path/to/build/directory/Monteverdi

export OTBAPPLICATIONS_SRC_DIR=path/to/sources/of/OTB-Applications
export OTBAPPLICATIONS_BUILD_DIR=/path/to/build/directory/OTB-Applications


export CFLAGS="-O2 -W -arch i386 "
export CXXFLAGS="-O2 -W  -arch i386 "
export LDFLAGS="-arch i386"

./configure \
--prefix=$GDAL_INSTALL_DIR \
--with-png=internal \
--with-libtiff=internal \

make install


cmake  \
-D GEOTIFF_INCLUDE_DIRS:PATH=$GDAL_SRC_DIR/frmts/gtiff/libgeotiff \
-D TIFF_INCLUDE_DIRS:PATH=$GDAL_SRC_DIR/frmts/gtiff/libtiff \
-D JPEG_INCLUDE_DIR:PATH=$GDAL_SRC_DIR/frmts/jpeg/libjpeg \
-D JPEG_INCLUDE_DIRS:PATH=$GDAL_SRC_DIR/frmts/jpeg/libjpeg \

cmake .



cmake  \



cmake  \


  • There is to compile OTB with an external fltk. You have to use fltk 1.3 (developement version) wich use Cocoa (64 bit Intel compilation). Issues: Enable to compile Monteverdi which is based on the library FLU. Compile fltk 1.3.x with the configure;make; make install" idiom. Compiling fltk 1.3.x with Cocoa support does not work yet.
This article is list of the problems that the users or OTB-Team have meet with MacOS.
Please feel free to correct, complete or improve it