Bug#812852: Vigra auf ppc64el -- continues a little bit

I upgraded the RC to use the newest LZ4 version which has significantly better byte order handling. Hopefully, this fixes the problem. One could also add a cmake option to use a pre-installed LZ4 library when available and just fall-back to the internal version if not. Best Ulli

Bug#812852: Vigra auf ppc64el -- continues a little bit

* Remove all occurencies of threading::memory_order* in multi_array_chunked.hxx (or equivalently, replace them with threading::memory_order_seq_cst). This will force all atomic accesses to use sequentially consistent ordering, the most strict possibility. That worked out ... much thanks! -

Bug#814606: libvigraimpex: FTBFS on armel (error: return type 'class std::future')

so, please run cmake with the flag "-DWITH_BOOST_THREAD=1". Yup, that works. Great. Ideally, we would like to activate this flag automatically for non-conforming compilers, or at least issue a warning. Is there a way for cmake to recognize your platform and toolchain? -- ** WARNING: You

Bug#814606: libvigraimpex: FTBFS on armel (error: return type 'class std::future')

Since your toolchain apparently has no conforming implementation of std::thread, you might want to try boost::thread as a fall-back. To do so, please run cmake with the flag "-DWITH_BOOST_THREAD=1". Best Ulli On Sat, 13 Feb 2016 13:27:16 +0100 Andreas Metzler wrote:

Bug#814606: libvigraimpex: FTBFS on armel (error: return type 'class std::future')

threadpool.hxx:333:26: error: return type 'class std::future' is incomplete ThreadPool::enqueue(F&& f) ^ This message is emitted by outdated compilers that lack sufficient C++11 support. What compiler did you use? If gcc: was the '-std=c++11' flag active? Best