Hi Emilio, On 4 October 2016 at 11:14, Emilio Pozuelo Monfort via llvm-dev <[email protected]> wrote: > In file included from /«PKGBUILDDIR»/lib/Support/ThreadPool.cpp:14:0: > /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In member function > 'std::shared_future<void> llvm::ThreadPool::async(Function&&, Args&& ...)': > /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h:78:77: error: return type > 'class std::shared_future<void>' is incomplete > inline std::shared_future<VoidTy> async(Function &&F, Args &&... ArgList) { > ^ > > Any idea about this failure? > > For the Debian armel porters, we're switching to LLVM 3.8, so this failure > (which happens on 3.8, 3.9 and llvm-toolchain-snapshot) is likely going to > cause > some package removals on armel as we try to get rid of older LLVM versions. > Helping fixing this issue would be appreciated to prevent that.
This looks like the kind of failure you get when your host toolchain doesn't support C++11 properly (specifically lock-free atomics in this case). When I've seen it before GCC was defaulting to a CPU that's too old to do atomics properly, and that configuration is very unlikely to be supported by LLVM ever (any more). It looks like Debian may only support ARMv7 for armel anyway, in which case you should add something like "-march=armv7-a" to your C flags (-DCMAKE_C_FLAGS=-march=armv7-a and possibly -DCMAKE_CXX_FLAGS=-march=armv7-a too). The earliest that you could possibly go and hope for it to work would be "armv6t2". Cheers. Tim.
