I am cross-compiling ROOT for armv7-a on a cortex-a9. With some patches to the build
this works fine for ROOT v6-13-02, but taking the latest commit, I am getting errors concerning
integer_sequence, see below. It seems like ROOT is declaring its own integer_sequence which
clashes with a previous declaration from my SDK. Any idea on what goes wrong and how to fix this?
Thanks for any help with this. Cheers,
Ralf
In file included from input_line_12:21:
In file included from ./etc/dictpch/allHeaders.h:922:
./include/ROOT/RIntegerSequence.hxx:88:8: error: redefinition of ‘integer_sequence’
struct integer_sequence {
^
/home2/spiwoks/build_pyro/sdk/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/include/c++/6.4.0/utility:296:12: note: previous definition is here
struct integer_sequence
^
In file included from input_line_12:21:
In file included from ./etc/dictpch/allHeaders.h:922:
./include/ROOT/RIntegerSequence.hxx:114:7: error: type alias template redefinition with different types (’__make_integer_sequence<_Tp, _Np>’ (aka ‘typename __make_integer_sequence_checked<type-parameter-0-0, _Ep>::type’) vs
‘typename _Make_integer_sequence<_Tp, _Num>::__type’)
using make_integer_sequence = __make_integer_sequence<_Tp, _Np>;
^
/home2/spiwoks/build_pyro/sdk/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/include/c++/6.4.0/utility:317:11: note: previous definition is here
using make_integer_sequence
^
Error: ./bin/rootcling: compilation failure (./allDicte35589ac13_dictUmbrella.h)
make[2]: *** [etc/allDict.cxx.pch] Error 1
Hi,
yes your assessment is correct, we recently added a C++11 backport of std::integer_sequence and related facilities. You also have a make_integer backport and when the ROOT intepreter runs on allHeaders.h it happens to see both and it complains.
Our backport falls back to the standard implementation from <utility> if, at cmake configuration time,
we detect that’s available (e.g. if you compile with -std=c++14 – which would be a valid workaround).
Since you already patch ROOT, another viable workaround would be to change the body of $ROOTSYS/core/foundation/inc/ROOT/RIntegerSequence.hxx to just #include your <utility> header with your backport.
Or, if you are sure that in your framework <utility> will always contain std::index_sequence & co. (with same API as the STL) you might be able to convince our build system that a “system” implementation is present by passing -DR__HAS_STD_INDEX_SEQUENCE=1 during ROOT compilation.
Pinging also @amadio and @Axel in case they have an opinion on how to deal with conflicting STL backports in general.
Note that technically the problem is that the cmake fragment that is suppose to detect whether the compiler ('s environment) provide an implementation of integer_sequence failed. Most likely the use of your SDK is trigger with some flags that is not pass down to the tester. How do you ‘request’ the use of your SDK for the ROOT compilation?
Thanks for your prompt reply. I was already using std=c++14 in CMAKE_CXX_FLAGS.
But that was, apparently, not sufficient. In fact, I saw that cxx11 is ON by default, and
std=c++11 gets added to CMAKE_CXX_FLAGS. Then the CMAKE_CXX_COMPILER
gets both arguments and seems to follow … std=c++11!!!
Anyway, if I set cxx14 in my toolchain file. Then it works, and I do get rid of the duplicated
declaration. I have not tried the other two possibilities.
Thanks for your reply. In the meantime, I have already found a solution by
setting the “cxx14” variable. Setting CMAKE_CXX_FLAGS = … -std=c++14
was not sufficient.
As for using a dedicated SDK, I am using cmake -DCMAKE_TOOLCHAIN_FILE=…
with the toolchain file provided by the SDK, Yocto in my case …
Hi Ralf,
yes, due to various complications in the build system (part of which related to shipping a c++ interpreter!)
ROOT requires that you set -Dcxx14=ON to get a c++14 compilation of the whole project.
As c++14 already has std::integer_sequence & friends, ROOT’s backport just falls back to that and there are no multiple definitions.