`libzt` on `arm`
aarlt opened this issue · comments
I tried compile libzt on an aarch64 linux machine. I'm getting the following errors:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h: In member function ‘void ZeroTier::AES::CTR::p_armCrypt(const uint8_t*, uint8_t*, unsigned int)’:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12438:1: error: inlining failed in call to always_inline ‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’: target specific option mismatch
12438 | vaeseq_u8 (uint8x16_t data, uint8x16_t key)
| ^~~~~~~~~
/home/alex/libzt/ext/ZeroTierOne/node/AES_armcrypto.cpp:160:18: note: called from here
160 | d0 = veorq_u8(vaeseq_u8(d0, k13), k14);
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/alex/libzt/ext/ZeroTierOne/node/Constants.hpp:121,
from /home/alex/libzt/ext/ZeroTierOne/node/AES_armcrypto.cpp:14:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12452:1: error: inlining failed in call to always_inline ‘uint8x16_t vaesmcq_u8(uint8x16_t)’: target specific option mismatch
12452 | vaesmcq_u8 (uint8x16_t data)
| ^~~~~~~~~~
Is there an easy way to solve these compilation problems?
I think those errors are mainly coming from your crypto algorithms. Maybe it would make sense to just replace them with something like Botan.
ZT proper definitely builds on that platform so it's just a matter of updating the libzt build process. I'll try to get you a patch today. We won't be adopting any new crypto libraries at this time however.
Ah interesting! Thats awesome! Thx!
Hmm.. just tried with ZF... it seem to have the same problem
[ 3%] Building CXX object CMakeFiles/zerotiercore.dir/node/AES_armcrypto.cpp.o
In file included from /home/alex/ZeroTierOne/node/Constants.hpp:130,
from /home/alex/ZeroTierOne/node/AES_armcrypto.cpp:14:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h: In member function ‘void ZeroTier::AES::CTR::p_armCrypt(const uint8_t*, uint8_t*, unsigned int)’:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12438:1: error: inlining failed in call to always_inline ‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’: target specific option mismatch
12438 | vaeseq_u8 (uint8x16_t data, uint8x16_t key)
| ^~~~~~~~~
/home/alex/ZeroTierOne/node/AES_armcrypto.cpp:160:18: note: called from here
160 | d0 = veorq_u8(vaeseq_u8(d0, k13), k14);
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/alex/ZeroTierOne/node/Constants.hpp:130,
from /home/alex/ZeroTierOne/node/AES_armcrypto.cpp:14:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12452:1: error: inlining failed in call to always_inline ‘uint8x16_t vaesmcq_u8(uint8x16_t)’: target specific option mismatch
12452 | vaesmcq_u8 (uint8x16_t data)
| ^~~~~~~~~~
/home/alex/ZeroTierOne/node/AES_armcrypto.cpp:159:20: note: called from here
159 | d0 = vaesmcq_u8(vaeseq_u8(d0, k12));
| ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
In file included from /home/alex/ZeroTierOne/node/Constants.hpp:130,
from /home/alex/ZeroTierOne/node/AES_armcrypto.cpp:14:
I am also interested in this issue here. Is there already a patch available? Thx!
@joseph-henry you where correct. ZeroTier compiles without any problems using make, the compilation just fails if cmake is used. I agree, updating the build system should solve this issue.
Can confirm that #179 fix this issue when cross-compiling against ARM64 on AMD64 Linux.
#179 is wrong because it assumes the optional Armv8A cryptography extension is always available.
This extension is optional and isn't available on many CPUs, e.g. Raspberry Pi 4 does not support it and will crash with "illegal instruction" at runtime.
I've filed #205 with more details and a proposal for a different approach.
Closing since solution was merged into upstream ZTO and the submodule was updated in libzt to include that fix. Thanks for your help everyone.