Comment 3 for bug 1349789

On 30 July 2014 14:59, Niall Douglas <email address hidden> wrote:
> FYI I am one of the Boost core dev team, and this problem emerged during
> our prerelease testing of Boost 1.56.
>
> I thought a reasonable test of who is at fault would be if I purged all
> trace of clang and llvm from the system, and then download these
> prebuilt binaries from llvm:
>
> http://llvm.org/releases/3.4.2/clang+llvm-3.4.2-armv7a-linux-
> gnueabihf.tar.xz
>
> I unpack these into /usr/local and ensure perms and ownership are reset
> to correct values.
>
> If I now repeat the earlier test I see:
>
> 1. I no longer need to manually override -mcpu, because the correct
> local CPU is now chosen and the atomics compile instead of the assembler
> not recognising instructions. I would assume the default triple of
> armv7a-linux-gnueabihf helps a lot here.
>

I believe our default clang triplet is the same as debian's, as we
don't modify it.
Which I think should be something is v7 without NEON.
Have you tried debian's armhf clang-3.4?
I'll investigate further to see what is the baseline cpu all three
target (ubuntu, debian and llvm upstream prebuilts)

> 2. All the unit tests still hang in the same place as with your clang.
>

=((((( *sad*

> This suggests to me that something is very wrong with Boost on clang on
> armhf.
>
> I'll investigate more this end, but fixing the default cpu such that it
> supports atomics would be a great help, so I'll leave this issue open
> for now. I'll come back if I figure out the cause of the hangs and it's
> related to packaging.
>

Ack.

--
Regards,

Dimitri.