> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry > Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto > extensions, but includes vmull and crc32 (vmull include arrangements > other than u8). The gadget also runs Raspian, which is a 32-bit OS > with hard floats. > > After Configure completes, the library's -march=armv7 takes precedence > over the user's -march=armv8-a{+crc}. > > $ ./config -march=armv8-a+crc -mtune=cortex-a53 > -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard
-mtune -mfloat-abi are more than sufficient in this case. Well, I wouldn't be surprised if -mfloat-abi is actually redundant, because it might be the default... And -march suggested by ./config is fine in this case. For reference, it would be fine even if processor in question had crypto extensions, because ARMv8 code is compiled even with -march=armv7-a. > ********** > > $ ./Configure linux-arm64ilp32 -march=armv8-a+crc -mtune=cortex-a53 > -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard linux-arm64ilp32 won't do. linux-arm64ilp32 is equivalent of x32 in x86_64 world. It takes 64-bit[!] kernel and dedicated run-time that adheres to 64-bit calling convention. Judging from ./config output you have 32-bit[!] kernel. For reference, note that you can run even linux-armv4 binaries under 64-bit kernel, and it's not same as ilp32. Just like on x86_64 you can run x86_64, x32 and x86 binaries, you can run "aarch64", "arm64ilp32" and 32-bit (hf or not) binaries under aarch64 kernel. Well, provided that you have corresponding libcs or linked statically... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4632 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev