Hi Everyone, My apologies for the late reply.
SL > There are various ways to reconcile this incompatibility between SL > build options, but given this is armhf which is guaranteed to have SL > floating-point support, I think the simplest may be as in the SL > attached patch, which adjusts to using -march=armv7-a+fp instead SL > of just -march=armv7-a. I have to admit I am a bit confused. armhf is hard floats, so the value can only be -mfloat-abi=hard unless it is explicitly changed. We don't change it. As far as I know, the code does not need the floating point unit or neon. In fact, we stopped using -mfloat-abi because we don't care what it is. The compiler default is fine by us. Would adding -mfpu=auto [1] be acceptable to you? I think that conveys the "don't care" attitude when compiling and assembling this source file. SL > However, I have not tested that this results in correct SL > behavior on armel, which is also still a Debian SL > architecture but not an Ubuntu architecture. LB > confirmed the problem and the fix as well on armhf in a LB > Sid chroot. Still need to check it on armel. armel is going to need CRYPTOPP_DISABLE_ARM_NEON defined in CPPFLAGS or CXXFLAGS. The reason is my ignorance. I don't know how to differentiate between armel and armhf in the preprocessor. They both look the same to us. Preprocessor macros don't change until we start adding options like -mfpu=neon. So, we assume armhf and make folks do something special for armel. armhf is the default because we believe it is the dominant use case. That is, we think there are more armv7 devices than armv6 or below devices.
