Can't build Crypto++ 8.6.0 for iOS in the M1 architecture

[brutalkeso]

Crypto++ Issue Report

crypto_version="CRYPTOPP_8_6_0"
function install_cryptopp_platform
{
    (
    set +u # Allow having undefined variables in setenv-ios.sh
    IOS_SDK="$1" IOS_CPU="$2" source ./TestScripts/setenv-ios.sh
    make -j"$NUM_PROC" -f GNUmakefile-cross
    make install -f GNUmakefile-cross PREFIX="$THIRDPARTY_INSTALL_PREFIX"
    mkdir -p "$THIRDPARTY_INSTALL_PREFIX/lib/crypto_$2"
    mv "$THIRDPARTY_INSTALL_PREFIX/lib/libcryptopp.a" "$THIRDPARTY_INSTALL_PREFIX/lib/crypto_$2"
    set -u
    )
}

function install_cryptopp
{
    echo "##teamcity[blockOpened name='cryptopp']"
    download_crypto
    local src_dir="cryptopp-$crypto_version"
    pushd "$src_dir"

    install_cryptopp_platform iPhoneOS arm64
    make clean

    install_cryptopp_platform iPhoneSimulator i386
    make clean

    local lib_arm64="$THIRDPARTY_INSTALL_PREFIX/lib/crypto_arm64/"
    local lib_i386="$THIRDPARTY_INSTALL_PREFIX/lib/crypto_i386/"

    lipo -create -output "$THIRDPARTY_INSTALL_PREFIX/lib/libcryptopp.a" "$lib_arm64/libcryptopp.a" "$lib_i386/libcryptopp.a"

    popd
    echo "##teamcity[blockClosed name='cryptopp']"
}

This works fine with 8_5_0, but not with 8_6_0. Then I get errors like:

clang++ -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.0.sdk -Wall -g2 -O3 -fPIC -arch arm64 -miphoneos-version-min=6 -stdlib=libc++ -fno-common -c dh.cpp
In file included from crc_simd.cpp:23:
./arm_simd.h:35:14: error: instruction requires: crc
    __asm__ ("crc32b   %w0, %w0, %w1   \n\t"
             ^
<inline asm>:1:2: note: instantiated into assembly here
        crc32b   w8, w8, w10   
        ^
In file included from crc_simd.cpp:23:
./arm_simd.h:68:14: error: instruction requires: crc
    __asm__ ("crc32w   %w0, %w0, %w1   \n\t"
             ^

Mac mini (M1, 2020) macOs BigSur 11.6

Apple clang version 13.0.0 (clang-1300.0.29.3)
Target: arm64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Xcode Version 13.0

[noloader]

Thanks @brutalkeso,

Unfortunately I cannot test this. I have an M1, and the GCC Compile Farm has a M1. Neither machine has Xcode.

I believe what changed is, we enabled CRC and GCM (polynomail multiply) in Crypto++ 8.6.

You may need to define CRYPTOPP_DISABLE_ARM_CRC32.

[erikbylow-vol]

How would I define that? make -j"$NUM_PROC" -f GNUmakefile-cross -CRYPTOPP_DISABLE_ARM_CRC32?

[noloader]

@erikbylow-vol,

Add it to CPPFLAGS in setenv-ios.sh. Change:

DEF_CPPFLAGS="-DNDEBUG"

to

DEF_CPPFLAGS="-DNDEBUG -DCRYPTOPP_DISABLE_ARM_CRC32"

DEF_CPPFLAGS is eventually used to create CPPFLAGS.

[JlidiBorhen]

That solved the compilation error in my case. But I haven't tested the library yet, will comment back here once that's done.

[JlidiBorhen]

That solved the compilation error in my case. But I haven't tested the library yet, will comment back here once that's done.

I confirm that the invoked functions from the library work as they should when adding the flag that @noloader mentioned (I haven't done any extensive testing though).

[noloader]

Thanks @JlidiBorhen.

I think we may be able to sidestep this issue on iOS, but we need to hack-in some byte codes instead of mnemonics. We should probably do it to avoid the compile error.

[noloader]

@brutalkeso, @erikbylow-vol, @JlidiBorhen,

If you have time could you test Master, please?

I think we cleared this issue with some recent changes to the makefiles. If not I would like to take another shot at it before the Crypto++ 8.7 release.

[Myriachan]

Wouldn't __attribute__((__target__("crc"))) work? Assuming that you're doing a runtime check somehow?

[noloader]

@Myriachan,

Function Multiversioning works well in C, but not C++. We tried it and it failed miserably.

I can't find the bug report I used to track a similar cut-in. But it was ugly. And then we had to pull it all back out because it caused so many problems.

[Myriachan]

@noloader

Oh, sorry, I don’t mean the multi-targeting feature of the target attribute. You can use this attribute on single functions rather than have multiple definitions of the same function.

Using the target attribute in this way tells the compiler that it has carte blanche to use those extended instructions where it feels like in that function—and allow the programmer to explicitly use those within the function. It’s like passing additional -m options, but for a single function.

The advantage is that you can do runtime feature detection. If you were to pass, say, -mavx as a compiler option, that would tell the compiler that it can use AVX instructions anywhere, including in non-SIMD code. This would be very bad with runtime feature detection.

This page mentions the feature: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

One minor annoyance I’ve noticed is that for ARM, Clang expects __target__("crc") whereas GCC expects a plus sign: __target__("+crc"). Not true for x86 though.

Crypto++ supports a much wider target/platform/compiler range than my own code, so this may not feasible.

[radioburst]

@brutalkeso, @erikbylow-vol, @JlidiBorhen,

If you have time could you test Master, please?

I think we cleared this issue with some recent changes to the makefiles. If not I would like to take another shot at it before the Crypto++ 8.7 release.

@noloader I don't know if you got a reply from them but I just tried to cross compile on a MacBookAir M1 for iPhoneOS15.4.sdk with the latest master of today (28.04) and got the same error as @brutalkeso. After editing DEF_CPPFLAGS it worked. It seems this error still persists.

EDIT: Hit me up if I should test something for you!

[jnavarrom]

Hello,

I have the same issue. Does the issue happen only on M1? Unfortunately, I don't have an intel mac here to test.

[noloader]

@jnavarrom,

Does the issue happen only on M1?

I believe the issue is specific to a M1.

The problem at the time of the bug report was, Apple Clang did not accept the CRC option. Then, we enabled the option anyways. The bug here is, we need to fix the "anyways". We should only enable CRC option when Apple Clang supports it. To do that, I need a test machine.

[jnavarrom]

I believe the issue is specific to a M1.

I will test it tomorrow on a Intel and let you know 👍.

The bug here is, we need to fix the "anyways". We should only enable CRC option when Apple Clang supports it. To do that, I need a test machine.

What machine do you need? A Mac with M1?

[jnavarrom]

I have the same compilation problems on a MacBook Pro (i5, 2014) macOs BigSur 11.6.8

Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Xcode 13.2.1

[crazydef]

I'm getting the same error building with xcode 10.1. (The newest version I can install on my old 2011 iMac.)