Bug#868779: clang: produces unusable binaries on armv5tel

[Adrian Bunk]

Control: severity -1 serious
Control: tags -1 patch
Control: clone -1 -2 -3 -4 -5
Control: reassign -1 clang-3.8
Control: reassign -2 clang-3.9
Control: reassign -3 clang-4.0
Control: reassign -4 clang-5.0
Control: reassign -5 clang-6.0

On Wed, Jul 19, 2017 at 03:06:23PM +0100, Ian Chard wrote:
> Hi,
> 
> After a bit of digging I found that using the clang option '-march=armv5t'
> fixes this for me.

Thanks for the report and debugging.

The problem is that clang currently takes the default from whatever CPU 
is on the machine thaqt built LLVM, and the Debian buildds are v7:

(stretch_armel-dchroot)bunk at abel:~$ clang-3.8 -dM -E - < /dev/null | grep "__ARM_ARCH "
#define __ARM_ARCH 7
(stretch_armel-dchroot)bunk at abel:~$ 

Packages in Debian built with clang (that are thankfully only few)
can also end up violating the armel baseline due to that.

Fix (tested with 3.8):

--- debian/rules.old	2017-08-25 22:45:31.957021979 +0000
+++ debian/rules	2017-08-25 22:45:36.251972982 +0000
@@ -55,6 +55,8 @@
   # 3.8 fails to build, disable the compiler_rt builtins
   # See http://lists.llvm.org/pipermail/llvm-dev/2016-May/099761.html
   CMAKE_EXTRA += -DCOMPILER_RT_BUILD_BUILTINS=OFF
+  # Prevent clang from getting a > v4t default
+  CMAKE_EXTRA += -DLLVM_HOST_TRIPLE=arm-linux-gnueabi
 endif
 
 ifeq ($(shell dpkg --compare-versions $(shell dpkg-query -W -f '$${Version}' g++-$(GCC_VERSION)) ge 4.8-20121128-1~ ; echo $$?),0)


> Cheers
> - Ian

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed