Fix arm-unknown-linux-gnueabi floating-point ABI

[joerg-krause]

gnueabi indicates soft whereas gnueabihf indicates hard floating-point ABI.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[MagaTailor]

What about -mfloat-abi=softfp? I believe on OpenPandora (at least for pure C/C++ code) this is the way to use the supported NEON instructions.

Maybe that was the original intention to be able to allow the obsolete vfp?

[joerg-krause]

The benefit of pure 'soft' binaries is that a soft app can run on a softfp system - but not vice versa.

[alexcrichton]

@bors: r+ 035a093

Thanks!

[bors]

⌛ Testing commit 035a093 with merge b0eec55...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[MagaTailor]

It offends my intelligence to see x86_64 builds/tests being run after changes to some arm .mk files or, as I'd noted previously, README.md!