Closed smessmer closed 2 years ago
Thanks @smessmer,
Any ideas on what could cause this?
We made some changes for Clang and I suspect this break is due to it. The changes happened a while ago, but I suspect the problem surfaced recently under GCC 11.
I try to get it cleared this week.
Also see GH #1094. I think its the same problem.
@smessmer,
Sorry about the late reply.
For armel, would it be possible for you to add CRYPTOPP_DISABLE_ARM_NEON
to your CPPFLAGS
. Something like:
$ CPPFLAGS="-DCRYPTOPP_DISABLE_ARM_NEON" make
Using testing flags: -DCRYPTOPP_DISABLE_ARM_NEON
g++ -DCRYPTOPP_DISABLE_ARM_NEON -DNDEBUG -g2 -O3 -fPIC -pthread -c cryptlib.cpp
g++ -DCRYPTOPP_DISABLE_ARM_NEON -DNDEBUG -g2 -O3 -fPIC -pthread -c cpu.cpp
g++ -DCRYPTOPP_DISABLE_ARM_NEON -DNDEBUG -g2 -O3 -fPIC -pthread -c integer.cpp
...
g++ -DCRYPTOPP_DISABLE_ARM_NEON -DNDEBUG -g2 -O3 -fPIC -pthread -c aria.cpp
g++ -DCRYPTOPP_DISABLE_ARM_NEON -DNDEBUG -g2 -O3 -fPIC -pthread -march=armv7-a -mfpu=neon -c aria_simd.cpp
g++ -DCRYPTOPP_DISABLE_ARM_NEON -DNDEBUG -g2 -O3 -fPIC -pthread -c ariatab.cpp
...
It seems to be testing OK on my RPI1, which is an ARMv6 machine without NEON. The options for aria_simd.cpp
are kind of weird. I'll need to look at that a little more. But the code path causing the compile failure should be removed.
I have not gotten to link yet. A link problem could rise up on us. Its going to take a few hours to get the full result back on this old Pi.
CRYPTOPP_DISABLE_ARM_NEON
is no loss since you don't have NEON anyways. NEON will be available on armhf platforms. That's where we want NEON in effect.
The trouble I've been having is, I can't seem to reliable determine a non-NEON platform, like armel.
pi@rpi1:~ $ uname -m
armv6l
pi@rpi1:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
@smessmer,
The options for aria_simd.cpp are kind of weird. I'll need to look at that a little more. But the code path causing the compile failure should be removed.
This oddity should be cleared with Commit 66d73d6d8b95.
@smessmer,
The tip of Master is fixed. We also got a bunch of CMake problems ironed out.
If you can wait about a week or two, then I'll release Crypto++ 8.7.
Or, you should be able to go with Crypto++ 8.6 but build with -DCRYPTOPP_DISABLE_ARM_NEON
defined. armel should be built with -DCRYPTOPP_DISABLE_ARM_NEON
but it failed to do so. If you add -DCRYPTOPP_DISABLE_ARM_NEON
manually, then you are doing what the build system should have done.
Crypto++ 8.6 may need Commit 4473b50803d0.
Details: https://github.com/cryfs/cryfs/issues/408
Trying to build CryFS 0.11.0 and 0.11.1 (which uses CryptoPP 8.5 and 8.6 respectively) fails on armel while CryFS 0.10.x (which uses CryptoPP 8.2) works fine.
The error message is
This was reported by the maintainer of the CryFS debian packages, it fails while trying to build the packages for Debian APT.
Any ideas on what could cause this?