On Thu, Aug 11, 2016 at 12:28:47PM +0200, Ximin Luo wrote: >Package: rustc >Version: 1.10.0+dfsg1-2 >Severity: normal > >Dear Maintainer, > >armhf currently fails to build on buildds but does build successfully on >porterbox harris.debian.org > >This is because rust upstream assumes arm-unknown-linux-gnueabi has neon: > >src/librustc_back/target/armv7_unknown_linux_gnueabihf.rs: >features: "+v7,+vfp3,+neon".to_string(), > >whereas Debian's armhf targets machines without neon, including all current >buildds, but only harris has it: > >infinity0@harris:~$ grep neon /proc/cpuinfo >Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls >vfpd32 > >The build fails running the upstream stage0 compiler because that contains >neon instructions. To fix this we'll have to > >1) patch rustc to not use neon, and >2) do a binary-only upload for armhf, either by > a) building on harris, but this takes 2-3 days > b) finding a faster armhf machine with neon to build it on, or > b) cross-compiling from another architecture
Ugh. *None* of the Linux distros doing ARMv7 hard-float assume NEON. The spec was agreed across the distros to explicitly *not* depend on NEON for these ports because it's optional and there are/were a number of ARMv7 CPUs in the wild without it. This appears to be utterly broken behaviour by rust upstream. -- Steve McIntyre, Cambridge, UK. st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
