Build fails on AArch64 when configured with "configure.py --cpu=arm32". Error: unrecognized command line option ‘-mfpu=neon’ #1442
Comments
|
I am confused. You indicate your GCC is configured for Aarch64. So, it is not possible to build for a standard 32-bit ARM target (which is what |
|
My intention is to build for arm32 on an arm64 machine. The same way one would build Botan 32 bit on X64 machine. It appears arm64 CPUs are able to run arm32 code, however Linuxes don't support mixed mode. I should be able to build though.
|
Execution works fine, but you need an arm32 compiler. In GCC at least, Aarch64 is a completely different backend from ARMv7 and company. |
|
Well, the build goes on just fine until it reaches the line where Full compilation output: |
It is building, but is it building ARMv7 object files? I'm guessing not. |
I went and replaced This shows that the offending flag preventing a 32 bit build on AArch64 is indeed Currently waiting to see if the resulting binary (botan-test) actually runs on |
|
You can test with |
It seems I'm not getting a 32 bit executable. Of course it won't work on |
|
... gives me a 64 bit build. Now I'm confused :| . |
|
You'll need a compiler for 32-bit ARM, which will come in a completely different package from Aarch64. Eg on Ubuntu 16.04, gcc-5-aarch64-linux-gnu for 64-bit vs gcc-5-arm-linux-gnueabihf for 32-bit. It doesn't work like x86-32 vs x86-64, which share a backend in GCC and a simple -m32/-m64 flag to switch targets. |
|
We have a compile-time check for x86-32 vs x86-64 cross-configuration because that's a common misconfiguration but for everwhere else, we just assume $CXX is going to produce binaries matching the CPU specified by We could/should have a better compile time check here, but fundamentally you need a different build of GCC for 32-bit ARM binaries. |
|
Oozing with clarity, I could sum it up thus:
This scenario is a rich source of massive fuck-ups, inviting the question: can |
|
That pretty well sums it up. It's fairly easy to check the compiler's predefined macros to detect what actual arch it intends to build for which I've done in #1443. It errors out if it detects an inconsistency between what the user expressed and what the compiler seems to be doing. |
|
It seems these changes don't pass CI. I'll test as soon as they do. |
This is kind of unusual. What does As @randombit said, you can't build for arbitrary hosts. You can only build for the host the compiler is setup for.
This does not make much sense; neither does Note that if you try to use You should probably ask some questions on the GCC Help mailing list to see what you need to accomplish what you want to do. I believe you are interested in responses from a fellow named James Greenhalgh. You might also want to talk with the Linaro folks. They may be able to help guide you with code generation needs. They have a GCC compiler mailing list. You are looking for responses from a fellow named Jim Wilson. Here is what I am seeing on a HiKey with GCC compiler, which is Aarch64. The first in the triplet, |
|
I apologize if I have not made my goals clear enough. The purpose of this exercise was to ascertain how would In this particular scenario, I did have the gcc-5-arm-linux-gnueabihf package installed, what I did not have was the aforementioned compiler incarnation set up as system default. The expectation was that The above expectation was not satisfied. The fruits of this (albeit uncanny) scenario materialized in @randombit 's stance on the subject:
and
I wish to take the opportunity to thank both @randombit and @noloader for the information made available in this thread. In retrospect, I do not believe this was a waste of time. :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The solution should be this.
The text was updated successfully, but these errors were encountered: