[llvm-dev] llvm-toolchain-3.8 on lower arm targets

[Tim Northover via llvm-dev]

Hi Emilio,

On 4 October 2016 at 11:14, Emilio Pozuelo Monfort via llvm-dev
<llvm-dev at lists.llvm.org> 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.