2018-12-10 07:27 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001502Orfeo Toolbox (OTB)Generalpublic2018-01-08 14:58
Assigned Togpasero 
Summary0001502: OTB configuration step does not properly check for c++14 availability
DescriptionOTB needs a c++14 compliant compiler to build. This should be checked during cmake configuration, but it does not seem to work correctly. For instance, with gcc 4.9 on CentOS, when using the SuperBuild, everything seems to work OK, all dependencies are built, but OTB compilation fails when compiling otbImageIOBase.cxx since in line 132 we introduced string literals.

[ 46%] Building CXX object Modules/Core/ImageBase/src/CMakeFiles/OTBImageBase.dir/otbImageIOBase.cxx.o
/opt/iota2-install/OTB/otb/Modules/Core/ImageBase/src/otbImageIOBase.cxx: In member function ‘virtual void otb::ImageIOBase::PrintSelf(std::ostream&, itk::Indent) const’:
/opt/iota2-install/OTB/otb/Modules/Core/ImageBase/src/otbImageIOBase.cxx:1323:24: erreur: ‘string_literals’ is not a namespace-name
using namespace std::string_literals;
/opt/iota2-install/OTB/otb/Modules/Core/ImageBase/src/otbImageIOBase.cxx:1323:39: erreur: expected namespace-name before ‘;’ token
using namespace std::string_literals;
/opt/iota2-install/OTB/otb/Modules/Core/ImageBase/src/otbImageIOBase.cxx:1324:19: erreur: unable to find string literal operator ‘operator"" s’
os << indent << "FileName: "s << m_FileName << std::endl;

TagsNo tags attached.
Attached Files




grizonnetm (administrator)

Last edited: 2017-12-21 16:38

View 2 revisions

I've removed the use of string_litterals in 6.2 and develop to maintain gcc 4.9 support:



gpasero (administrator)

Here is a first try:

We could do things a bit differently using CMake COMPILE_FEATURES :

CMake can check that the compiler supports a given feature before building a target (executable/library). Using the command target_compile_features(), we can specify that a given target needs for instance 'cxx_override' or 'cxx_range_for'.

However, the operator 's' in string_literals doesn't really fit in CMake known features (it should be linked to paper N3642, which doesn't appear in the list).

Any thoughts?


grizonnetm (administrator)

+1 for a "soft fix" like you propose with a warning during cmake configuration

I don't think that we need for now to get into CMake COMPILE_FEATURES for now.

BTW, do we need to do something for people who would try to compile otb version >= 6.0 with Visual Studio.

Re"garding recent thread on gdal-dev there are some issues with VS 2013 support of c++11:



julien (administrator)

Last edited: 2018-01-08 10:33

View 3 revisions

I think the current fix is good :
1) remove the string litteral which is merely there for causing artificial compilation errors on old compilers.
2) During configuration time, check for compiler version and issue an explicit "unsupported compiler" warning for gcc < 5.0.0, visual < ???? and clang < ????. If the user chooses to ignore the warning, OTB may or may not compile depending on which c++14 features are supported by her compiler.


gpasero (administrator)

Check of compiler versions added for GNU (>=5.0), Clang (>=3.5), and MSVC (>=19)



grizonnetm (administrator)

you mean clang >= 3.4:


The patch is ok


julien (administrator)

The patch is ok, but I would prefer an even more explicit message :

"WARNING: the version of your ${CMAKE_CXX_COMPILER_ID} is not supported by Orfeo ToolBox (c++14 support might be incomplete). Please consider updating your compiler to version ${OTB_MIN_${CMAKE_CXX_COMPILER_ID}_VER} or later."


gpasero (administrator)

Message fixed :

-Issue History
Date Modified Username Field Change
2017-12-19 09:33 inglada New Issue
2017-12-21 16:17 grizonnetm Assigned To => grizonnetm
2017-12-21 16:17 grizonnetm Status new => assigned
2017-12-21 16:36 grizonnetm Status assigned => closed
2017-12-21 16:36 grizonnetm Resolution open => fixed
2017-12-21 16:36 grizonnetm Note Added: 0004455
2017-12-21 16:38 grizonnetm Note Edited: 0004455 View Revisions
2017-12-22 11:45 grizonnetm Assigned To grizonnetm =>
2017-12-22 11:45 grizonnetm Status closed => new
2017-12-22 11:45 grizonnetm Resolution fixed => reopened
2017-12-22 11:45 grizonnetm Priority normal => urgent
2018-01-03 15:08 gpasero Assigned To => gpasero
2018-01-03 15:08 gpasero Status new => assigned
2018-01-03 16:58 gpasero Note Added: 0004458
2018-01-04 17:08 grizonnetm Note Added: 0004464
2018-01-08 10:31 julien Note Added: 0004478
2018-01-08 10:32 julien Note Edited: 0004478 View Revisions
2018-01-08 10:33 julien Note Edited: 0004478 View Revisions
2018-01-08 11:25 gpasero Status assigned => resolved
2018-01-08 11:25 gpasero Resolution reopened => fixed
2018-01-08 11:25 gpasero Note Added: 0004479
2018-01-08 11:29 grizonnetm Note Added: 0004481
2018-01-08 11:59 julien Note Added: 0004482
2018-01-08 14:58 gpasero Note Added: 0004485
+Issue History