noloader / cryptopp-cmake

CMake files for Crypto++ project

Crypto++ CMake

IMPORTANT

⚠️ This repo's last release is CRYPTOPP_8_6_0 and will no longer be maintained by its current maintainers. It will remain for people who want to use cmake < 2.8 and for whoever want to take that maintenance over.

A new repo has been created at https://github.com/abdes/cryptopp-cmake but for modern cmake users, i.e. cmake version >= 3.21. Feel free to move to that repo which will continue to be maintained and track crypto++ future releases. You are also welcome to become a contributor in that repo.

⚠️ This repo will soon be placed in read-only mode.

Old README

This repository contains CMake files for Wei Dai's Crypto++ (https://github.com/weidai11/cryptopp). It supplies CMakeLists.txt and cryptopp-config.cmake for Crypto++ for those who want to use CMake. CMake is officialy unsupported, so use it at your own risk.

The purpose of Crypto++ CMake is two-fold:

1. better support Linux distributions, like Gentoo
2. provide users with centrally maintained CMake project files

The initial cryptopp-config.cmake and CMakeLists.txt were taken from the library sources when CMake support was dropped. Also see CMake on the Crypto++ wiki for some history and how to use CMake with Crypto++.

Documentation

The CMake project files are documented on the Crypto++ wiki | CMake. If there is an error or ommission in the wiki article, then please fix it or open a bug report.

Testing

The CMake files are officialy unsupported, so use them at your own risk. With that said, the CMake source files are tested with Crypto++ on Linux and OS X using Travis CI.

In June 2018 the library added cryptest-cmake.sh to help test the CMake gear. The script is located in Crypto++'s TestScripts directory. The script downloads the CMake project files, builds the library and then runs the self tests.

If you want to use cryptest-cmake.sh to drive things then perform the following steps.

cd cryptopp
cp TestScripts/cryptest-cmake.sh .
./cryptest-cmake.sh

Workflow

The general workflow is clone Wei Dai's crypto++, add CMake as a submodule, and then copy the files of interest into the Crypto++ directory:

git clone https://github.com/weidai11/cryptopp.git
cd cryptopp

wget -O CMakeLists.txt https://raw.githubusercontent.com/noloader/cryptopp-cmake/master/CMakeLists.txt
wget -O cryptopp-config.cmake https://raw.githubusercontent.com/noloader/cryptopp-cmake/master/cryptopp-config.cmake

Despite our efforts we have not been able to add the submodule to Crypto++ for seamless integration. If anyone knows how to add the submodule directly to the Crypto++ directory, then please provide the instructions.

ZIP Files

If you are working from a Crypto++ release zip file, then you should download the same cryptopp-cmake release zip file. Both Crypto++ and this project use the same release tags, such as CRYPTOPP_8_0_0.

If you mix and match Master with a release zip file then things may not work as expected. You may find the build project files reference a source file that is not present in the Crypto++ release.

Integration

The CMake submodule integrates with the Crypto++ library. The library's GNUmakefile and GNUmakefile-cross were modified to clean the artifacts produced by CMake. To clean the directory after running CMake perform a git checkout GNUmakefile followed by a make -f GNUmakefile distclean.

Collaboration

We would like all distro maintainers to be collaborators on this repo. If you are a distro maintainer then please contact us so we can send you an invite.

If you are a collaborator then make changes as you see fit. You don't need to ask for permission to make a change. Noloader is not an CMake expert so there are probably lots of opportunities for improvement.

Keep in mind other distros may be using the files, so try not to break things for the other guy. We have to be mindful of lesser-used platforms and compilers, like AIX, Solaris, IBM xlC and Oracle's SunCC.

License

Everything in this repo is release under Public Domain code. If the license or terms is unpalatable for you, then don't feel obligated to use it or commit.

cryptopp-cmake's Issues

Several source files are missing from CMakeList.txt

Hi,

I'm installing cryptopp using CMake on my windows computer, it seems that in the latest version (version 7.00) of cryptopp there isn't anymore some previous sources files. So the execution of cmake command gives an error at the moment it try to add to the executable (line 1085):

CMake Error at CMakeLists.txt:1085 (add_executable):
Cannot find source file:
C:/Program Files/CryptoPP/cryptopp-CRYPTOPP_7_0_0/bench3.cpp

Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx

CMake Error at CMakeLists.txt:1085 (add_executable):
No SOURCES given to target: cryptest

It refers to the cryptopp_SOURCES_TEST whee the files.cpp are added :

• bench3.cpp (line 522)
• validat5/6/7/8/9/10.cpp (lines 528-533)
• regtest4.cpp (line 537)

When i commented those lines, the cmake execution worked. Maybe it needs to be updated.

Add conditional compilation of aes-armv4.S

Due to Issue 683 and Commit 3ff7d7f0286a we need to add conditional compilation of aes-armv4.S for CMake.

The makefile has the following:

IS_ARM32 := $(shell echo "$(HOSTX)" | $(GREP) -i -c -E 'arm|armhf|arm7l|eabihf')
...

ifeq ($(IS_ARM32),1)
    CRYPTOGAMS_AES_ARCH = -march=armv7-a -marm
    SRCS += aes-armv4.S
endif
...

ifeq ($(IS_ARM32),1)
aes-armv4.o : aes-armv4.S
    $(CC) $(strip $(CXXFLAGS) $(CRYPTOGAMS_AES_ARCH) -mfloat-abi=$(FP_ABI) -c) $<
endif

The recipe should only be in effect for ARM A-32 systems with GNU AS (GAS). ARM Ltd's assembler may be able to assemble it too, but I have not tested it. The recipe should not be in effect for Aarch32, Aarch64, MIPS, x86_64, Windows, etc.

A similar rule was already added to the Autotools project.

This task is open to any takers. I've had enough fun with jobs like this. Someone else will have to {enjoy|suffer} it.

Apple Silicon support - cryptest-cmake.sh fails

• cmake v3.19.1
• Xcode 12.2, macOS Big Sur
• Apple M1 arm64
• cryptopp commit 49157a3 (current master)
• cryptopp-cmake commit 33e33e9 (current master)

cryptest-cmake.sh fails compiling Crypto++/crc_simd.cpp

error: use of undeclared identifier '__crc32b'
error: use of undeclared identifier '__crc32w'
error: use of undeclared identifier '__crc32cb'
error: use of undeclared identifier '__crc32cw'

Not sure what to check, tbh. Suspecting a configuration error, so I'm asking here.
Any hints would be much appreciated!

Build fails: unknown target 'shared'

I tried to incorporate the cmake build into the FreeBSD port, but it fails:

-- Build files have been written to: /usr/ports/security/cryptopp/work/cryptopp-7.0.0
===>  Building for cryptopp-7.0.0
ninja: error: unknown target 'shared'
===> Compilation failed unexpectedly.

I extracted the project into the cmake directory, and copied back into the root of the project:

post-extract:
        @cd ${WRKSRC} && ${MKDIR} cmake && cd cmake && tar xzf ${DISTDIR}/noloader*cmake* --strip 1 && ${CP} * ..

ARM build not adding aes-arm.S when neon is available

The source file was being adding before the compiler option checks are done. Therefore it was missed in all cases.

Import library cryptopp-shared.lib does not appear to be generated or installed on windows

I think that it should be in PREFIX/lib/ next to cryptopp-static.lib.

It seems that cryptopp is not exporting any symbol on windows.

cryptest-cmake.sh now available

Hi Everyone,

cryptest-cmake.sh now available in TestScripts. The script downloads the CMake files to $(PWD), creates a build directory, and then builds the library and executes self tests.

To use the script:

cd cryptopp
git pull
cp TestScripts/cryptest-cmake.sh .
./cryptest-cmake.sh

After the script runs the CMake files are left in place so they can be used again in the future.

There is also a cryptest-autotools.sh that works the same way for Autotools.

Xcode check is not correct?

f56dba1

should be:

if(CMAKE_GENERATOR STREQUAL Xcode)

endif()

Build fails on i.MX6 (error: inlining failed)

Build fails with errors like this one (cross-compile on an x86_64 Linux for a Linux running on an i.MX6 with g++ 9.2.1):

error: inlining failed in call to always_inline 'void vst1q_u8(uint8_t*, uint8x16_t)': target specific option mismatch

Cause: The platform is not detected correctly. Thus incorrect compiler options are inferred:

-- Platform: x86_64

Changing the else branch of

function(DumpMachine output pattern)

  if (MSVC)

    # CMake does not provide a generic shell/terminal mechanism
    #  and Microsoft environments don't know what 'sh' is.
    set(${output} 0 PARENT_SCOPE)

  else ()
      if(CMAKE_SYSTEM_PROCESSOR MATCHES ${pattern})
          set(${output} TRUE PARENT_SCOPE)
      endif()
  endif()

endfunction(DumpMachine)

back to the old version from 8.2.0

function(DumpMachine output pattern)

  if (MSVC)

    # CMake does not provide a generic shell/terminal mechanism
    #  and Microsoft environments don't know what 'sh' is.
    set(${output} 0 PARENT_SCOPE)

  else ()
    execute_process(
      COMMAND sh -c "${CMAKE_CXX_COMPILER} -dumpmachine 2>&1"
      COMMAND ${GREP_CMD} -i -c -E "${pattern}"
      OUTPUT_VARIABLE ${output}
      OUTPUT_STRIP_TRAILING_WHITESPACE)
    set(${output} "${${output}}" PARENT_SCOPE)
  endif()

endfunction(DumpMachine)

in CMakeLists.txt fixes the problem.

CMake Error at CMakeLists.txt: "STREQUAL" "SunOS"

I'm testing on GCC112 on the compile farm:

CMake Error at CMakeLists.txt:151 (if):
  if given arguments:

    "STREQUAL" "SunOS"

  Unknown arguments specified

-- Configuring incomplete, errors occurred!
cmake failed

Here is the line in CmakeList.txt:

if (${CMAKE_SYSTEM_NAME} STREQUAL "SunOS")
  set(GREP_CMD /usr/xpg4/bin/grep)
  set(SED_CMD /usr/xpg4/bin/sed)
else()
  set(GREP_CMD grep)
  set(SED_CMD sed)
endif ()

ping @abdes. Would you mind taking a look at this? It looks like the break was introduced before we created this repository. The pain point here is, (1) CMake does not define the variable that is being used and (2) there's no way I know of to get a portable terminal to run commands (assuming you want to run uname).

Also see GCC Compile Farm Accounts for Testing.

RPI cross compile fails

Hi

I am trying to build cryptopp using cmake in Raspberry PI cross compile ,but i am getting this error.

-- Performing Test CRYPTOPP_ARMV7A_NEON
-- Performing Test CRYPTOPP_ARMV7A_NEON - Failed
-- Performing Test CRYPTOPP_ARMV7A_HARD
-- Performing Test CRYPTOPP_ARMV7A_HARD - Failed
-- Performing Test CRYPTOPP_ARMV7A_SOFTFP
-- Performing Test CRYPTOPP_ARMV7A_SOFTFP - Failed
CMake Error at buildARM/_deps/cryptopp-src/CMakeLists.txt:264 (if):
if given arguments:

"" "NOT" "STREQUAL" ""

Unknown arguments specified
Call Stack (most recent call first):
buildARM/_deps/cryptopp-src/CMakeLists.txt:734 (AddCompileOption)

Any idea what cause fails cmake build fail ?

Building on cortex-a53

I ran in this error while trying to build Crypto++ on cortex A53

[ 39%] Building CXX object 3rdparty/cryptopp/CMakeFiles/cryptopp-object.dir/gf2n.cpp.o
cd <redacted> && <redacted>$
-gnu-g++ -mcpu=cortex-a53 -ldl -lrt -lpthread -fPIC -static-libstdc++ -fvisibili
ty-inlines-hidden -fvisibility=hidden -fdata-sections -ffunction-sections  -DUSE
_NEON -DZYNQ_FPGA -DZYNQ_ULTRASCALE -I<redacted> -I<redacted> -I<redacted> -I<re
dacted> -W -Wall -Wno-unknown-pragmas -Wno-unused-variable -Wno-unused-parameter
 -O3 -g -fno-omit-frame-pointer -lm -lrt -pthread  -Wno-reorder -Wno-missing-fie
ld-initializers -std=c++14 -lm -lrt -pthread -Wno-reorder -Wno-missing-field-ini
tializers -Wno-class-memaccess -Wno-deprecated  -fPIC   -o CMakeFiles/cryptopp-o
bject.dir/gf2n.cpp.o -c <redacted>/cryptopp/gf2n.cpp
/tmp/ccZ8ov9y.s: Assembler messages:
/tmp/ccZ8ov9y.s:216: Error: selected processor does not support `pmull v0.1q,v0.1d,v3.1d'
/tmp/ccZ8ov9y.s:251: Error: selected processor does not support `pmull2 v1.1q,v1.2d,v2.2d'
/tmp/ccZ8ov9y.s:487: Error: selected processor does not support `pmull v5.1q,v0.1d,v5.1d'
/tmp/ccZ8ov9y.s:569: Error: selected processor does not support `pmull v0.1q,v0.1d,v6.1d'
/tmp/ccZ8ov9y.s:754: Error: selected processor does not support `pmull v2.1q,v0.1d,v3.1d'
/tmp/ccZ8ov9y.s:808: Error: selected processor does not support `pmull v5.1q,v1.1d,v3.1d'
/tmp/ccZ8ov9y.s:861: Error: selected processor does not support `pmull v1.1q,v0.1d,v1.1d'
/tmp/ccZ8ov9y.s:888: Error: selected processor does not support `pmull2 v0.1q,v0.2d,v3.2d'
/tmp/ccZ8ov9y.s:985: Error: selected processor does not support `pmull v4.1q,v2.1d,v4.1d'
/tmp/ccZ8ov9y.s:1091: Error: selected processor does not support `pmull v2.1q,v2.1d,v6.1d'
/tmp/ccZ8ov9y.s:1461: Error: selected processor does not support `pmull v2.1q,v0.1d,v17.1d'
/tmp/ccZ8ov9y.s:1523: Error: selected processor does not support `pmull v1.1q,v1.1d,v17.1d'
/tmp/ccZ8ov9y.s:1578: Error: selected processor does not support `pmull v19.1q,v16.1d,v7.1d'
/tmp/ccZ8ov9y.s:1605: Error: selected processor does not support `pmull2 v0.1q,v16.2d,v4.2d'

Apparently this is the only compilation problem. Can anyone help me figure this one out?

Add chacha-simd.cpp

@abdes,

We added chacha-simd.cpp, and provided both x86 and ARM acceleration.

Do you want to try the cut-in for x86, ARM and Aarch64?

You can test your changes with ./cryptest-cmake.sh. ./cryptest-cmake.sh is located in TestScripts/. Just copy it up to the root directory and run it.

Cannot find source file: TestPrograms/test_x86_sse2.cxx

MacOS Catalina, CLion 2020.3 Build #CL-203.5981.166, built on December 2, 2020.

I simply include the CMakeList.txt provided in my project. Then, the "Cannot find source file" comes out. However, I checked the file exist.

May I ask how to deal with this issue?

Thank you very much!

====================[ Build | secretsharing | Debug ]===========================
/Applications/CLion.app/Contents/bin/cmake/mac/bin/cmake --build /Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug --target secretsharing -- -j 6
-- *************************************************************************
The Crypto++ library does not officially support CMake. CMake support is a
community effort, and the library works with the folks using CMake to help
improve it. If you find an issue then please fix it or report it at
https://github.com/noloader/cryptopp-cmake.
-- *************************************************************************
-- CMake version 3.17.3
-- Performing Test CRYPTOPP_IA32_SSE2
CMake Error at /Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug/CMakeFiles/CMakeTmp/CMakeLists.txt:14 (add_executable):
  Cannot find source file:

    /Users/<my user name>/CLionProjects/secretsharing/TestPrograms/test_x86_sse2.cxx

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx

CMake Error at /Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug/CMakeFiles/CMakeTmp/CMakeLists.txt:14 (add_executable):
  No SOURCES given to target: cmTC_581a2

CMake Error at cryptopp/CMakeLists.txt:246 (try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  cryptopp/CMakeLists.txt:551 (CheckCompileLinkOption)
  CMakeLists.txt:6 (include)

-- Configuring incomplete, errors occurred!
See also "/Users/<my user name>/CLionProjects/secretsharing/cmake-build-debug/CMakeFiles/CMakeOutput.log".
make: *** [cmake_check_build_system] Error 1

For cmake >= 3.1.0 use CMP0054 NEW to remove warning due to comparison with "MSVC"

CMake Warning (dev) at CMakeLists.txt:200 (if):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "MSVC" will no longer be dereferenced when the policy
  is set to NEW.  Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
  CMakeLists.txt:220 (DumpMachine)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:367 (if):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "MSVC" will no longer be dereferenced when the policy
  is set to NEW.  Since the policy is not set the OLD behavior will be used.
This warning is for project developers.  Use -Wno-dev to suppress it.

These warnings are because we set the minimum required version of cmake to 2.8.12 while on the build environment we may be using a much more recent version.

Configuring with ninja fails

If the Ninja generator is used on Ubuntu 20.04 (which seems to be the default in VSCode CMake Tools) the configuration and build fails:

CMake Error:
  Running

   '/usr/bin/ninja' '-C' '/home/michael/Prog/Cpp/AuthVaultCore/build' '-t' 'recompact'

  failed with:

   ninja: warning: phony target 'third_party/cryptopp/cryptest.exe' names itself as an input; ignoring [-w phonycycle=warn]

  ninja: error: build.ninja:1883: multiple rules generate
  third_party/cryptopp/cryptest.exe [-w dupbuild=err]

Cryptocpp is added as a submodule via git and a subdirectory in cmake

cmake_minimum_required(VERSION 3.10)
project(TestCrypto LANGUAGES CXX VERSION 0.0.1)

add_subdirectory(${CMAKE_SOURCE_DIR}/third_party/cryptopp)
add_subdirectory(${CMAKE_SOURCE_DIR}/src)

It seems like Ninja doesn't like it when the executable is renamed to .exe and added as a dependency to itself ( https://github.com/noloader/cryptopp-cmake/blob/master/CMakeLists.txt#L1054-L1061 )
PS: Removing the lines actually fixes the issue, but I don't know if that would break compatibility with other systems. I don't really know if they serve any purpose.

Should we move aarch32 to CRYPTOPP_ARM32 variable?

As far as I understood aarch32 is an alias for armv8 32bit. According to this should we apply this diff?

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -299,8 +299,8 @@ DumpMachine(CRYPTOPP_AMD64 "(x86_64|AMD64|amd64)")
 DumpMachine(CRYPTOPP_I386 "^i.86$")
 DumpMachine(CRYPTOPP_MINGW32 "^mingw32")
 DumpMachine(CRYPTOPP_MINGW64 "(w64-mingw32)|(mingw64)")
-DumpMachine(CRYPTOPP_ARMV8 "(armv8|aarch32|aarch64)")
-DumpMachine(CRYPTOPP_ARM32 "(arm|armhf|arm7l|eabihf)")
+DumpMachine(CRYPTOPP_ARMV8 "(armv8|aarch64)")
+DumpMachine(CRYPTOPP_ARM32 "(arm|armhf|arm7l|eabihf|aarch32)")
 DumpMachine(CRYPTOPP_PPC32 "^(powerpc|ppc)")
 DumpMachine(CRYPTOPP_PPC64 "^ppc64")
 

Please add -qxlcompatmacros when using IBM XL C/C++ on PowerPC

GCC112 is ppc64-le on the GCC compile farm. It looks like IBM cutover to LLVM for some of its compiler components. XL C/C++ no longer defines __xlc__ and __xlC__ by default. The result is a failed compile as Clang gets into code paths it can't handle even though it defines __GNUC__. Also see Where did XL C/C++ predefined macros go on GCC112? on the cfarm mailing list.

The workaround is to use -qxlcompatmacros for IBM XL C/C++ when available.

The GNUmakefile already has the patch. Autotools will be receiving it shortly. Autotools received the patch.

Please add -qxlcompatmacros to CXXFLAGS with IBM XL C/C++ on PowerPC when available.

Doesn't install cmake files

In the FreeBSD port (security/cryptopp) I expected that the cmake-based build would install cmake files, so that other projects would be able to find it through cmake scripts.

But the list of files that it installs is identical.

Please install cmake files.

Add distro maintainers as collaborators

@alonbl, @Guozht, @Azer0s, @anonimal, @wildbiotiger, @UKMonkey, @UKMonkey, @Marc--Olivier, @Romain-Geissler-1A, @ZahlGraf, @nexussafe, @egorpugin, @HeinrichJanzing, @geoffbeier, @FloriansGit, @steady286, @zabulus, @morozovcookie, @GamePad64,

We moved our Autools files and CMake files to my GitHub. It allows them to be more "online" than the wiki and establish provenance by using a known GitHub. Using a separate GitHub also allows us to establish a boundary so users implicitly know the files are not part of the library, but available if desired. Finally, this is the sort of administrivia WD prefers to avoid, so I don't want to ask WD for a repo in his GitHub (at the moment).

Autools files and CMake are not officially supported, so use at your own risk. The community is still expected to help maintain them. If the community can get them into a good state, then we can consider moving them into the library proper.

If you are a maintainer of a distro or package, then please ping me so I can invite you as a collaborator on this GitHub. You don't need to ask permission to make changes. Just fix the problems that surface. My email address is noloader, gmail account.

It looks like CMake does not support MinGW32

Can't compile an application that uses Crypto++ in the most current version 7.0.

The compiler i use is mingw32, the development environment is eclipse ide for c/c++ developers version "photon release 4.8.0"

09:58:28 **** Build of configuration Release for project MACAddressToPiUserPassword ****
make all 
Building file: ../indiv-build/CMakeFiles/3.6.2/CompilerIdCXX/CMakeCXXCompilerId.cpp
Invoking: Cross G++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"indiv-build/CMakeFiles/3.6.2/CompilerIdCXX/CMakeCXXCompilerId.d" -MT"indiv-build/CMakeFiles/3.6.2/CompilerIdCXX/CMakeCXXCompilerId.o" -o "indiv-build/CMakeFiles/3.6.2/CompilerIdCXX/CMakeCXXCompilerId.o" "../indiv-build/CMakeFiles/3.6.2/CompilerIdCXX/CMakeCXXCompilerId.cpp"
Finished building: ../indiv-build/CMakeFiles/3.6.2/CompilerIdCXX/CMakeCXXCompilerId.cpp
 
Building file: ../indiv-build/CMakeFiles/3.6.2/CompilerIdC/CMakeCCompilerId.c
Invoking: Cross GCC Compiler
gcc -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"indiv-build/CMakeFiles/3.6.2/CompilerIdC/CMakeCCompilerId.d" -MT"indiv-build/CMakeFiles/3.6.2/CompilerIdC/CMakeCCompilerId.o" -o "indiv-build/CMakeFiles/3.6.2/CompilerIdC/CMakeCCompilerId.o" "../indiv-build/CMakeFiles/3.6.2/CompilerIdC/CMakeCCompilerId.c"
Finished building: ../indiv-build/CMakeFiles/3.6.2/CompilerIdC/CMakeCCompilerId.c
 
Building file: ../indiv-build/CMakeFiles/feature_tests.c
Invoking: Cross GCC Compiler
gcc -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"indiv-build/CMakeFiles/feature_tests.d" -MT"indiv-build/CMakeFiles/feature_tests.o" -o "indiv-build/CMakeFiles/feature_tests.o" "../indiv-build/CMakeFiles/feature_tests.c"
Finished building: ../indiv-build/CMakeFiles/feature_tests.c
 
Building file: ../include/crypto++/3way.cpp
Invoking: Cross G++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"include/crypto++/3way.d" -MT"include/crypto++/3way.o" -o "include/crypto++/3way.o" "../include/crypto++/3way.cpp"
Finished building: ../include/crypto++/3way.cpp
 
Building file: ../include/crypto++/adler32.cpp
Invoking: Cross G++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"include/crypto++/adler32.d" -MT"include/crypto++/adler32.o" -o "include/crypto++/adler32.o" "../include/crypto++/adler32.cpp"
Finished building: ../include/crypto++/adler32.cpp
 
Building file: ../include/crypto++/algebra.cpp
Invoking: Cross G++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"include/crypto++/algebra.d" -MT"include/crypto++/algebra.o" -o "include/crypto++/algebra.o" "../include/crypto++/algebra.cpp"
Finished building: ../include/crypto++/algebra.cpp
 
Building file: ../include/crypto++/algparam.cpp
Invoking: Cross G++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"include/crypto++/algparam.d" -MT"include/crypto++/algparam.o" -o "include/crypto++/algparam.o" "../include/crypto++/algparam.cpp"
Finished building: ../include/crypto++/algparam.cpp
 
Building file: ../include/crypto++/arc4.cpp
Invoking: Cross G++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"include/crypto++/arc4.d" -MT"include/crypto++/arc4.o" -o "include/crypto++/arc4.o" "../include/crypto++/arc4.cpp"
Finished building: ../include/crypto++/arc4.cpp
 
Building file: ../include/crypto++/aria-simd.cpp
Invoking: Cross G++ Compiler
g++ -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"include/crypto++/aria-simd.d" -MT"include/crypto++/aria-simd.o" -o "include/crypto++/aria-simd.o" "../include/crypto++/aria-simd.cpp"
../include/crypto++/aria-simd.cpp: In function 'void CryptoPP::ARIA_ProcessAndXorBlock_Xor_SSSE3(const byte*, CryptoPP::byte*, const byte*, CryptoPP::word32*)':
../include/crypto++/aria-simd.cpp:122:76: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
  const __m128i MASK = _mm_set_epi8(12,13,14,15, 8,9,10,11, 4,5,6,7, 0,1,2,3);
                                                                            ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:714:1: error: inlining failed in call to always_inline 'void _mm_storeu_si128(__m128i*, __m128i)': target specific option mismatch
 _mm_storeu_si128 (__m128i *__P, __m128i __B)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:144:65: note: called from here
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
                                                                 ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:1286:1: error: inlining failed in call to always_inline '__m128i _mm_xor_si128(__m128i, __m128i)': target specific option mismatch
 _mm_xor_si128 (__m128i __A, __m128i __B)
 ^~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:696:1: error: inlining failed in call to always_inline '__m128i _mm_loadu_si128(const __m128i*)': target specific option mismatch
 _mm_loadu_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/crypto++/aria-simd.cpp:14:0:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:136:1: error: inlining failed in call to always_inline '__m128i _mm_shuffle_epi8(__m128i, __m128i)': target specific option mismatch
 _mm_shuffle_epi8 (__m128i __X, __m128i __Y)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:690:1: error: inlining failed in call to always_inline '__m128i _mm_load_si128(const __m128i*)': target specific option mismatch
 _mm_load_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:611:1: error: inlining failed in call to always_inline '__m128i _mm_set_epi8(char, char, char, char, char, char, char, char, char, char, char, char, char, char, char, char)': target specific option mismatch
 _mm_set_epi8 (char __q15, char __q14, char __q13, char __q12,
 ^~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:122:76: note: called from here
  const __m128i MASK = _mm_set_epi8(12,13,14,15, 8,9,10,11, 4,5,6,7, 0,1,2,3);
                                                                            ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:714:1: error: inlining failed in call to always_inline 'void _mm_storeu_si128(__m128i*, __m128i)': target specific option mismatch
 _mm_storeu_si128 (__m128i *__P, __m128i __B)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:152:49: note: called from here
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
                                                 ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:1286:1: error: inlining failed in call to always_inline '__m128i _mm_xor_si128(__m128i, __m128i)': target specific option mismatch
 _mm_xor_si128 (__m128i __A, __m128i __B)
 ^~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:149:19: note: called from here
   _mm_storeu_si128(M128_CAST(outBlock),
   ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    _mm_xor_si128(
    ~~~~~~~~~~~~~~  
     _mm_loadu_si128(CONST_M128_CAST(outBlock)),
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:696:1: error: inlining failed in call to always_inline '__m128i _mm_loadu_si128(const __m128i*)': target specific option mismatch
 _mm_loadu_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:149:19: note: called from here
   _mm_storeu_si128(M128_CAST(outBlock),
   ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    _mm_xor_si128(
    ~~~~~~~~~~~~~~  
     _mm_loadu_si128(CONST_M128_CAST(outBlock)),
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:696:1: error: inlining failed in call to always_inline '__m128i _mm_loadu_si128(const __m128i*)': target specific option mismatch
 _mm_loadu_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:149:19: note: called from here
   _mm_storeu_si128(M128_CAST(outBlock),
   ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    _mm_xor_si128(
    ~~~~~~~~~~~~~~  
     _mm_loadu_si128(CONST_M128_CAST(outBlock)),
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:714:1: error: inlining failed in call to always_inline 'void _mm_storeu_si128(__m128i*, __m128i)': target specific option mismatch
 _mm_storeu_si128 (__m128i *__P, __m128i __B)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:144:65: note: called from here
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
                                                                 ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:1286:1: error: inlining failed in call to always_inline '__m128i _mm_xor_si128(__m128i, __m128i)': target specific option mismatch
 _mm_xor_si128 (__m128i __A, __m128i __B)
 ^~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:696:1: error: inlining failed in call to always_inline '__m128i _mm_loadu_si128(const __m128i*)': target specific option mismatch
 _mm_loadu_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/crypto++/aria-simd.cpp:14:0:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:136:1: error: inlining failed in call to always_inline '__m128i _mm_shuffle_epi8(__m128i, __m128i)': target specific option mismatch
 _mm_shuffle_epi8 (__m128i __X, __m128i __Y)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:690:1: error: inlining failed in call to always_inline '__m128i _mm_load_si128(const __m128i*)': target specific option mismatch
 _mm_load_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:611:1: error: inlining failed in call to always_inline '__m128i _mm_set_epi8(char, char, char, char, char, char, char, char, char, char, char, char, char, char, char, char)': target specific option mismatch
 _mm_set_epi8 (char __q15, char __q14, char __q13, char __q12,
 ^~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:122:76: note: called from here
  const __m128i MASK = _mm_set_epi8(12,13,14,15, 8,9,10,11, 4,5,6,7, 0,1,2,3);
                                                                            ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:714:1: error: inlining failed in call to always_inline 'void _mm_storeu_si128(__m128i*, __m128i)': target specific option mismatch
 _mm_storeu_si128 (__m128i *__P, __m128i __B)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:144:65: note: called from here
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
                                                                 ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:1286:1: error: inlining failed in call to always_inline '__m128i _mm_xor_si128(__m128i, __m128i)': target specific option mismatch
 _mm_xor_si128 (__m128i __A, __m128i __B)
 ^~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:696:1: error: inlining failed in call to always_inline '__m128i _mm_loadu_si128(const __m128i*)': target specific option mismatch
 _mm_loadu_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../include/crypto++/aria-simd.cpp:14:0:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:136:1: error: inlining failed in call to always_inline '__m128i _mm_shuffle_epi8(__m128i, __m128i)': target specific option mismatch
 _mm_shuffle_epi8 (__m128i __X, __m128i __Y)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:690:1: error: inlining failed in call to always_inline '__m128i _mm_load_si128(const __m128i*)': target specific option mismatch
 _mm_load_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:142:18: note: called from here
  _mm_storeu_si128(M128_CAST(outBlock),
  ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
   _mm_xor_si128(_mm_loadu_si128(CONST_M128_CAST(outBlock)),
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    _mm_shuffle_epi8(_mm_load_si128(CONST_M128_CAST(rk)), MASK)));
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:714:1: error: inlining failed in call to always_inline 'void _mm_storeu_si128(__m128i*, __m128i)': target specific option mismatch
 _mm_storeu_si128 (__m128i *__P, __m128i __B)
 ^~~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:152:49: note: called from here
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
                                                 ^
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:1286:1: error: inlining failed in call to always_inline '__m128i _mm_xor_si128(__m128i, __m128i)': target specific option mismatch
 _mm_xor_si128 (__m128i __A, __m128i __B)
 ^~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:149:19: note: called from here
   _mm_storeu_si128(M128_CAST(outBlock),
   ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    _mm_xor_si128(
    ~~~~~~~~~~~~~~  
     _mm_loadu_si128(CONST_M128_CAST(outBlock)),
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:696:1: error: inlining failed in call to always_inline '__m128i _mm_loadu_si128(const __m128i*)': target specific option mismatch
 _mm_loadu_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:149:19: note: called from here
   _mm_storeu_si128(M128_CAST(outBlock),
   ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    _mm_xor_si128(
    ~~~~~~~~~~~~~~  
     _mm_loadu_si128(CONST_M128_CAST(outBlock)),
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\pmmintrin.h:31:0,
                 from c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\tmmintrin.h:31,
                 from ../include/crypto++/aria-simd.cpp:14:
c:\development\compilers\c++\minigw\lib\gcc\mingw32\6.3.0\include\emmintrin.h:696:1: error: inlining failed in call to always_inline '__m128i _mm_loadu_si128(const __m128i*)': target specific option mismatch
 _mm_loadu_si128 (__m128i const *__P)
 ^~~~~~~~~~~~~~~
../include/crypto++/aria-simd.cpp:149:19: note: called from here
   _mm_storeu_si128(M128_CAST(outBlock),
   ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    _mm_xor_si128(
    ~~~~~~~~~~~~~~  
     _mm_loadu_si128(CONST_M128_CAST(outBlock)),
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     _mm_loadu_si128(CONST_M128_CAST(xorBlock))));
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [include/crypto++/aria-simd.o] Error 1

09:58:43 Build Failed. 26 errors, 1 warnings. (took 15s.406ms)

CheckCompileLinkOption fails when Xcode compiler is invoked from command line

When testing for the compiler capabilities with:

CheckCompileLinkOption("-msse2" CRYPTOPP_IA32_SSE2 "${TEST_PROG_DIR}/test_x86_sse2.cxx")

CheckCompileLinkOption invokes the CMAKE_CXX_COMPILER directly and compiles the test file. This file will fail to compile with an error message that it can't locate stdlib.h, when the compiler is clang from the xcode toolchain. Try to run:

/Applications/Xcode9.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -msse2 test_x86_sse2.cxx

This is the error:

In file included from test_x86_sse2.cxx:1:
In file included from /Applications/Xcode9.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/emmintrin.h:27:
In file included from /Applications/Xcode9.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/xmmintrin.h:39:
In file included from /Applications/Xcode9.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include/mm_malloc.h:27:
/Applications/Xcode9.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdlib.h:94:15: fatal error: 'stdlib.h' file not found
#include_next <stdlib.h>
              ^~~~~~~~~~
1 error generated.

However as soon as you add the -isysroot pointing to the correct sysroot, compiles without a problem.

This seems to be a problem with the compilers in this path in the toolchain, the clang in /usr/bin/ works fine.

So, there should be a way to modify CmakeLists to take the sysroot into account, but I'm not sure what would be the elegant way to do that...

OpenMP

By default, when using the cryptopp-cmake script, or when depending on cryptopp via Conan, it seems to build without OpenMP.

For the cryptopp-cmake script, I worked around this so far by adding my own hacks around it in a separate CMakeLists.txt, and to be honest, those hacks are somewhat complicated, see here: https://github.com/cryfs/cryfs/blob/38575f258a16c2dd847013749c93eaefe1c58af0/vendor/cryptopp/CMakeLists.txt

I would like to switch that project to Conan, but that means I won't be able to use this hack anymore. OpenMP would have to be supported natively by the cryptopp conan package, which I think means that cryptopp-cmake would have to natively support it.

Are there plans to add OpenMP build functionality? Possibly some code from the hack I linked above could be copied, it seems to be relatively cross-platform.

Problem compiling in ARM7

When compiling in ARM7 and these options CRYPTOPP_ARMV7A_HARD, CRYPTOPP_ARMV7A_SOFTFP are not applied, the AddCompileOption("-DCRYPTOPP_DISABLE_NEON") faild because there are an error in:

cryptopp-cmake/CMakeLists.txt

Line 264 in b97d72f

if ("${COMMAND_OUTPUT}" NOT STREQUAL "")

It works with change to:

if (NOT "${COMMAND_OUTPUT}" STREQUAL "")
      list(APPEND CRYPTOPP_COMPILE_OPTIONS "${opt}")
endif ()

Cryptopp 8 fails to build on macOS Xcode 10

crypto++8.0.0 release

macOS 10.14.2, Xcode 10.1
$ clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0

Cmake (from cryptopp-cmake project) static lib
$ cmake --version
cmake version 3.12.2

Building for macOS target. Not iPhone simulator.

Copied from weidei/cryptopp issue

crypto++7 built fine

cryptopp/crc_simd.cpp:148:13: error: always_inline function '_mm_crc32_u8' requires target feature 'popcnt', but would be inlined into function 'CRC32C_Update_SSE42' that is compiled without support for 'popcnt'
        c = _mm_crc32_u8(c, *s);
            ^
cryptopp/crc_simd.cpp:151:13: error: always_inline function '_mm_crc32_u32' requires target feature 'popcnt', but would be inlined into function 'CRC32C_Update_SSE42' that is compiled without support for 'popcnt'
        c = _mm_crc32_u32(c, *(const word32 *)(void*)s);
            ^
/cryptopp/crc_simd.cpp:154:13: error: always_inline function '_mm_crc32_u8' requires target feature 'popcnt', but would be inlined into function 'CRC32C_Update_SSE42' that is compiled without support for 'popcnt'
        c = _mm_crc32_u8(c, *s);
            ^
3 errors generated.

Source for the function is wrapped by CRYPTOPP_SSE42_AVAILABLE and that checks for CRYPTOPP_APPLE_CLANG_VERSION >= 40000.

However, compiler flags do not have SSE4.2 enabled by default:

$ c++ -arch x86_64 -std=c++14 -dM -E -x c++ - < /dev/null | grep SSE
#define __SSE2_MATH__ 1
#define __SSE2__ 1
#define __SSE3__ 1
#define __SSE4_1__ 1
#define __SSE_MATH__ 1
#define __SSE__ 1
#define __SSSE3__ 1

In Xcode this can be overrode with the "Enable Additional Vector Extensions" whose raw name is "CLANG_X86_VECTOR_INSTRUCTIONS".

Please add VERSION to cmake project()

-- *************************************************************************
The Crypto++ library does not officially support CMake. CMake support is a
community effort, and the library works with the folks using CMake to help
improve it. If you find an issue then please fix it or report it at
https://github.com/noloader/cryptopp-cmake.
-- *************************************************************************
CMake Warning (dev) at cmake-build-debug/cryptopp-src/CMakeLists.txt:19 (project):
  Policy CMP0048 is not set: project() command manages VERSION variables.
  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  The following variable(s) would be set to empty:

    PROJECT_VERSION
    PROJECT_VERSION_MAJOR
    PROJECT_VERSION_MINOR
    PROJECT_VERSION_PATCH
This warning is for project developers.  Use -Wno-dev to suppress it.

Cannot find source file: /usr/ports/security/cryptopp/work/cryptopp-7.0.0_1/bench3.cpp

While trying in the FreeBSD port context, it fails:

-- Configuring done
CMake Error at CMakeLists.txt:1086 (add_executable):
  Cannot find source file:

    /usr/ports/security/cryptopp/work/cryptopp-7.0.0_1/bench3.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx


CMake Error at CMakeLists.txt:1086 (add_executable):
  No SOURCES given to target: cryptest

rev. b97d72f
cryptopp-7.0.0

How to use?

The "how to use" issue did not make sense because it referred to the Crypto++ Wiki page that is prior to the time when this repository was created.

I use macOS Catalina with Xcode11.4.1, have cloned Crypto++ and then used this CMakeLists.txt file. It SEEMS that everything works because the config is created and when I "build" cryptopp-static, it says "successful". But I cannot find any lib/a/binary files in my build folder.

cryptopp-shared does not compile because it directly jumps to creating symlinks and then, clearly, says that it cannot find any dylib.

Any ideas?

Unknown CMake command "cryptopp_target_compile_properties".

I'm testing on GCC112, which is a ppc64-le machine. It is running:

$ cmake --version
cmake version 2.8.12.2

Running cmake ../ from a build directory results in:

-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- SRC_DIR: /home/cryptopp
CMake Error at CMakeLists.txt:716 (cryptopp_target_compile_properties):
  Unknown CMake command "cryptopp_target_compile_properties".

How To Use?

This appears to be actively maintained, but what do I need to include in my project's CMakeLists.txt to make it work? I'm attempting this on CentOS with the lines:

find_package(CryptoPP REQUIRED)
target_link_libraries(libbiocoin cryptopp-static)

But receive the error:

CMake Error at 3rdparty/src/cryptopp/cryptopp-config.cmake:1 (include):
  include could not find load file:

    /var/www/apps/TeamCity/buildAgent/work/36bdf8bfb90be80c/src/libbiocoin/3rdparty/src/cryptopp/cryptopp-targets.cmake
Call Stack (most recent call first):
  CMakeLists.txt:58 (find_package)


-- Configuring incomplete, errors occurred!

When running cmake -DCMAKE_BUILD_TYPE=Debug in my project directory. The Crypto++ package is installed via the instructions in the readme for cryptopp-cmake in the subdirectory 3rdparty/src/cryptopp/

Any help would be appreciated (and might be worth adding to the readme itself.)

Question: Using FetchContent_Declare() with FetchContent_GetProperties()

Since most of the CMakeLists files in the Crypto++ repository end with an answer that it was a failed experiment I try my luck here. My project uses the SEAL library and if I use this CMakeLists with Crypto++ then it somehow messes with the seal header files.

I use CLion on Fedora 32 and my goal is to be able to use

#include <secblock.h>
using secure_string = std::basic_string<char, std::char_traits<char>, CryptoPP::AllocatorWithCleanup<char>>;

In my project. Is it possible to import Crypto++ as an INTERFACE using:

# Get the cryptopp package
set(CRYPTOPP "cryptopp")
FetchContent_Declare(
        ${CRYPTOPP}
        GIT_REPOSITORY  https://github.com/weidai11/cryptopp
        GIT_TAG         CRYPTOPP_8_2_0
)

FetchContent_GetProperties(${CRYPTOPP})
if(NOT ${CRYPTOPP}_POPULATED)
    FetchContent_Populate(${CRYPTOPP})

    # Temporal as long as the project doesn't include CMakeLists.txt in a proper way. If that changes use:
    #add_subdirectory(${${CRYPTOPP}_SOURCE_DIR} ${${CRYPTOPP}_BINARY_DIR})
endif()

# The next two lines are Temporal as long as the project doesn't include CMakeLists.txt in a proper way:
#include_directories(${${CRYPTOPP}_BINARY_DIR})
add_library(${CRYPTOPP} INTERFACE)
target_include_directories(${CRYPTOPP} INTERFACE ${${CRYPTOPP}_SOURCE_DIR})


# Link the project libraries to the executable
target_link_libraries(my_project PRIVATE
    ${CRYPTOPP}
)

I'm not sure if I'll need to add:

add_executable(my_project
    ${${CRYPTOPP}_SOURCE_DIR}/<some header or source files>
)
target_link_libraries(my_project PRIVATE
    ${CRYPTOPP}
)

I'm asking because this doesn't work for Crypto++ but has worked for me with a different library that also doesn't use CMakeLists.txt file e.g.:

# Get the tinyfiledialogs package
set(TINY_FILE_DIALOGS "tinyfiledialogs")
FetchContent_Declare(
        ${TINY_FILE_DIALOGS}
        GIT_REPOSITORY  https://git.code.sf.net/p/tinyfiledialogs/code
        GIT_TAG         87597a # v3.6.3
)
FetchContent_GetProperties(${TINY_FILE_DIALOGS})
if(NOT ${TINY_FILE_DIALOGS}_POPULATED)
    FetchContent_Populate(${TINY_FILE_DIALOGS})
    # Temporal as long as the project doesn't include CMakeLists.txt in a proper way. If that changes use:
    #add_subdirectory(${${TINY_FILE_DIALOGS}_SOURCE_DIR} ${${TINY_FILE_DIALOGS}_BINARY_DIR})
endif()
# The next two lines are Temporal as long as the project doesn't include CMakeLists.txt in a proper way:
#include_directories(${${TINY_FILE_DIALOGS}_BINARY_DIR})
add_library(${TINY_FILE_DIALOGS} INTERFACE)
target_include_directories(${TINY_FILE_DIALOGS} INTERFACE ${${TINY_FILE_DIALOGS}_SOURCE_DIR})

add_executable(my_project
    ${${TINY_FILE_DIALOGS}_SOURCE_DIR}/tinyfiledialogs.c
)
target_link_libraries(my_project PRIVATE
    ${TINY_FILE_DIALOGS}
)

Disable avx/avx2, make compilation failed

Hi,
when I deactivated avx/avx2 the compilation of cryptopp failed on (chacha_avx.cpp).
It seems that the flag --mavx (or similar) is missing and should be present event if avx if disabled.
I see it when I compile cryptopp using the Makefile provided with cryptoo.
Regards,

Support Crypto++ 8.6

Wil this support Crypto++ 8.6?

GCC Compile Farm Accounts for Testing

@alonbl, @Guozht, @Azer0s, @anonimal, @wildbiotiger, @UKMonkey, @UKMonkey, @Marc--Olivier, @Romain-Geissler-1A, @ZahlGraf, @nexussafe, @egorpugin, @HeinrichJanzing, @geoffbeier, @FloriansGit, @steady286, @zabulus, @morozovcookie, @GamePad64, @solvingj,

One of the ways we test Crypto++ is through the GCC Compile Farm. The compile farm is open to anyone working on free and open software projects. The farm provides access to additional hardware, operating systems and compilers, like PowerPC and PPC-64, Aarch64, AIX, and IBM XL C/C++ compiler.

Another good testing practice is to buy a few inexpensive dev-boards, like a BeagleBone, CubieTruck and MIPS Creator. They offer you local ARM and MIPS testing for 30 to 50 US dollars. And don't forget Android because its NDK uses some unusual flags, like -mfloat-abi=soft (Linux usually uses hard floats).

Yet another good testing practice is to setup VMs with Solaris and some of the BSDs, like OpenBSD, FreeBSD, NetBSD and DragonFly. Solaris is one of the most frustrating platforms to work on, so be sure to have one handy for testing. Sun's C++ compiler is full of surprises.

Finally, Debian Chroots are useful for testing Debian. You get access to the supported ports and some unsupported ports. Be sure to visit the Crypto++ wiki documentation at Debian Chroots. It has the recipes to set up the chroots.

CMake testing on some of the lesser used platforms will go a long way in promoting the stability of the CMake project files.

Setting DISABLE_ASM to ON breaks Visual Studio 2008 and lower builds

When building using Visual Studio 2008 or lower, ASM is required. See cpu.cpp:59.

MSVC static runtime library

According to https://www.cryptopp.com/wiki/Visual_Studio cryptopp should favor static linking against the C/C++ runtime (/MT or /MTd).

When I use this cmake project with visual studio or ninja generator, I keep getting dynamically linked runtime. You can test this by searching the build.ninja output file for "\MD" or "\MT".

My cmake command is

cmake -G Ninja -DBUILD_SHARED=OFF -DBUILD_STATIC=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX=C:\cryptopp -DCMAKE_BUILD_TYPE=Release ..

How can we switch between static and dynamic linking with this project?
According to https://cmake.org/cmake/help/latest/variable/CMAKE_MSVC_RUNTIME_LIBRARY.html#variable:CMAKE_MSVC_RUNTIME_LIBRARY and https://cmake.org/cmake/help/latest/prop_tgt/MSVC_RUNTIME_LIBRARY.html
we should be able to use CMAKE_MSVC_RUNTIME_LIBRARY as a global variable or MSVC_RUNTIME_LIBRARY as a target specific property to choose the desired option. I tried setting these variables to "MultiThreaded" but it did not have an effect (I do successfully use these variables in my own projects).

I was able to do a find-and-replace "/MD" to "/MT" in the build.ninja file and successfully built with static linked runtime library, so there shouldn't be issues with the build. We just need to figure out how to switch between the two in cmake instead of having to manually edit the ninja or visual studio output file.

OS: Windows 10
Compiler: MSVC/14.28.29333
CMake: 3.19

can not build static lib with Xcode generator

mkdir cryptopp-build
cd cryptopp-build
cmake ../cryptopp-CRYPTOPP_7_0_0 -G Xcode

When I build cryptopp-static target, there is no libcryptopp.a file. Because of this:

echo "Depend check for xcode"
Depend check for xcode
cd /Users/beemaster/dev/test/cryptopp-build && make -C /Users/beemaster/dev/test/cryptopp-build -f /Users/beemaster/dev/test/cryptopp-build/CMakeScripts/XCODE_DEPEND_HELPER.make PostBuild.cryptopp-object.Debug
/bin/rm -f /Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.dylib
/bin/rm -f /Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.a

Looked inside XCODE_DEPEND_HELPER.make

# Rules to remove targets that are older than anything to which they
# link.  This forces Xcode to relink the targets from scratch.  It
# does not seem to check these dependencies itself.
PostBuild.cryptest.Debug:
PostBuild.cryptopp-static.Debug: /Users/beemaster/dev/test/cryptopp-build/Debug/cryptest.exe
/Users/beemaster/dev/test/cryptopp-build/Debug/cryptest.exe:\
	/Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.a
	/bin/rm -f /Users/beemaster/dev/test/cryptopp-build/Debug/cryptest.exe


PostBuild.cryptopp-object.Debug:
PostBuild.cryptopp-shared.Debug:
PostBuild.cryptopp-object.Debug: /Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.dylib
/Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.dylib:\
	/Users/beemaster/dev/test/cryptopp-build/cryptopp.build/Debug/cryptopp-object.build/Objects-normal/libcryptopp-object.a
	/bin/rm -f /Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.dylib


PostBuild.cryptopp-static.Debug:
PostBuild.cryptopp-object.Debug: /Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.a
/Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.a:\
	/Users/beemaster/dev/test/cryptopp-build/cryptopp.build/Debug/cryptopp-object.build/Objects-normal/libcryptopp-object.a
	/bin/rm -f /Users/beemaster/dev/test/cryptopp-build/Debug/libcryptopp.a

Any idea why cmake generated such a stupid postbuild?

On Aix32 machine Cryptopp build is fail

Aix machine on 7.1 version. For Aix32 cryptopp build is fail with below error.

/renxbuilds/cryptoppupgrade/COMMON/Cryptopp820/blake2b_simd.cpp:756:8: error: 'uint64x2_p' does not name a type
 inline uint64x2_p VecLoad64(const void* p)^M
        ^
/renxbuilds/cryptoppupgrade/COMMON/Cryptopp820/blake2b_simd.cpp:765:8: error: 'uint64x2_p' does not name a type
 inline uint64x2_p VecLoad64LE(const void* p)^M
        ^
/renxbuilds/cryptoppupgrade/COMMON/Cryptopp820/blake2b_simd.cpp:776:39: error: 'uint64x2_p' does not name a type
 inline void VecStore64(void* p, const uint64x2_p x)^M
                                       ^
/renxbuilds/cryptoppupgrade/COMMON/Cryptopp820/blake2b_simd.cpp:776:50: error: ISO C++ forbids declaration of 'x' with no type [-fpermissive]
 inline void VecStore64(void* p, const uint64x2_p x)^M
                                                  ^
/renxbuilds/cryptoppupgrade/COMMON/Cryptopp820/blake2b_simd.cpp: In function 'void CryptoPP::VecStore64(void*, int)':
/renxbuilds/cryptoppupgrade/COMMON/Cryptopp820/blake2b_simd.cpp:781:17: error: 'uint8x16_p' was not declared in this scope

Missing compiler id

When building cryptopp on apple (compiler id AppleClang) the build will fail, due to missing architecture flags. This is because in L432

if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
                          ^^^^^^^^

we expect Clang. The right way is to check for both of them: e.g. CMAKE_CXX_COMPILER_ID MATCHES "Clang".

Furthermore, test headers missing ${CMAKE_CURRENT_SOURCE_DIR}/factory.h and test sources validat4.cpp.

---

I can't place code under Public Domain, due to german copyright restrictions. So I cannot create a pull request or is CC0 1.0 valid?

Please add -mrdrnd and -mrdseed to rdrand.cpp

Uri reported a failure of RDSEED when using CMake. Also see Travis | Job 404134554.

Please add feature tests for RDRAND and RDSEED, and add -mrdrnd and -mrdseed to rdrand.cpp as the features are available. The rdrand.cpp source file is kind of unique in that it may have one or two flags depending on availability.

STREQUAL comparison with "MSVC" is too restrictive

Build environments that return a full string for MSVC including the version info will fail due to the comparison with STREQUAL.

A better approach is to use the cmake built-in variable 'MSVC' which is defined if the compiler is MSVC or an equivalent compiler.

Fix multi-line string concatenation for older versions of cmake

The warning status message uses '' for line continuation which does not reliably work below cmake 3.0.0. A more universal approach is to use string concatenation:

if(cryptocpp_DISPLAY_CMAKE_SUPPORT_WARNING)
  message( STATUS
"*************************************************************************\n"
"The Crypto++ library does not officially support CMake. CMake support is a\n"
"community effort, and the library works with the folks using CMake to help\n"
"improve it. If you find an issue then please fix it or report it at\n"
"https://github.com/noloader/cryptopp-cmake.\n"
"-- *************************************************************************"
)
endif()

Cannot find header file <winapifamily.h>

Removing the line in CMakeLists.txt adding the winapifamily include resolves that issue.

CMake 3.10 or higher is required. You are running version 3.7.2

Testing on gcc117.fsffrance.org (Aarch64/ARMv8-a) results in:

CMake Error at CMakeLists.txt:22 (cmake_minimum_required):
  CMake 3.10 or higher is required.  You are running version 3.7.2

-- Configuring incomplete, errors occurred!

We are not administrators on the GCC Compile Farm. We cannot install software.

CMakeList.txt adds Python dependencies

I was looking through CMakeList.txt. I noticed CMakeList.txt has a Python dependency:

if(NOT EXISTS ${SRC_DIR}/${_landmark})
    message(FATAL_ERROR "Failed to locate python source.
The searched locations were:
   <CMAKE_CURRENT_SOURCE_DIR>
   <CMAKE_CURRENT_SOURCE_DIR>/${_extracted_dir}
   <CMAKE_CURRENT_BINARY_DIR>/../${_extracted_dir}
   <SRC_DIR>
You could try to:
  1) download cryptopp
  2) extract the archive in folder: ${_parent_dir}/${_extracted_dir}
  3) Check that file \"${_parent_dir}/${_extracted_dir}/${_landmark}\" exists.
  4) re-configure.
If you already downloaded the source, you could try to re-configure this project passing -DSRC_DIR:PATH=/path/to/Python-{PY_VERSION} using cmake or adding an PATH entry named SRC_DIR from cmake-gui.")
endif()

I'm mostly ignorant to CMake so forgive my knowledge gaps. We usually don't want to add additional requirements to build things. We want things to "just work" for users. Requiring users to download and install Python kind of nullifies the "it just works" we are aiming for.

Crosscompiling for Android on Windows (MinGW32)

Hello,

I'm having trouble compiling the app for Android from Windows x64, using MinGW32.
I get an error as soon as compilation starts:

clang++.exe: error: unsupported option '--sysroot C:/AndroidPlayerNDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa -Wformat -Werror=format-security -stdlib=libc++ '
CMakeFiles\cryptopp-object.dir\build.make:74: recipe for target 'CMakeFiles/cryptopp-object.dir/cryptlib.cpp.o' failed

The library does compile with no problem for Windows, MacOS and iOS and I do succeed in cross-compiling other libraries (such as OpenCV) for Android so I don't really know where the problem can come from.
I can also cross-compile the library using the official Makefile (following those instructions) so it really does not seem to be a minGW32 setup problem.

Does anybody have any idea on how to fix this, or any pointer on how to debug this?
Thank you,
PS: I'm not sure if this is the right place to post, I apologize if it's not.

Windows build fails due to non-existing winpipes.cpp file

There is no such file anymore as winpipes.cpp in the crypto++ library, which makes the build on windows/mingw fail at the construction of the cryptopp_SOURCES list.

-- Build type: 
-- Configuring done
CMake Error at CMakeLists.txt:696 (add_library):
  Cannot find source file:
    C:/projects/cryptopp/winpipes.cpp
  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx
CMake Error at CMakeLists.txt:696 (add_library):
  No SOURCES given to target: cryptopp-object

weidai11/cryptopp#705

What i did to link cryptopp and cryptocpp-cmake

Hey!

In README.md you're asking for suggestions, here's what I did:

git submodule add https://github.com/noloader/cryptopp-cmake
git submodule add https://github.com/weidai11/cryptopp.git
cd cryptocpp
ln -s ../cryptopp-cmake/ .
ln -s cryptopp-cmake/cryptopp-config.cmake .

Then on the README.md, instruct to run the following (or create a script that automatically sets up the repository):

git submodule update --init --recursive
cd cryptocpp
ln -s ../cryptopp-cmake/ .
ln -s cryptopp-cmake/cryptopp-config.cmake .

This will have almost the same effect of the instructions given with the added benefit that you get build consistency, because everything is a submodule pointing to the same commit hash for everyone.

CheckCompilerOption is misdetecting PowerPC options

Due to some bad interactions with Clang, GCC and XLC on PowerPC we needed to tighten up some slop in the way we detect PowerPC features. CheckCompilerOption is misdetecting features now because an empty main is not enough. For example, an empty main reports the following on a POWER7 machine with a compiler that lacks POWER8:

-- Performing Test PPC_ALTIVEC_FLAG
-- Performing Test PPC_ALTIVEC_FLAG - Success
-- Option -mcpu=power7 -maltivec
-- Performing Test PPC_POWER7_FLAG
-- Performing Test PPC_POWER7_FLAG - Success
-- Option -mcpu=power8 -maltivec
-- Performing Test PPC_POWER8_FLAG
-- Performing Test PPC_POWER8_FLAG - Success

However, when we go to use POWER8 with a builtin like vec_add then a compile error surfaces.

[ 10%] Building CXX object CMakeFiles/cryptopp-object.dir/blake2s_simd.cpp.o
/home/noloader/cryptopp/blake2b_simd.cpp: In function 'void CryptoPP::BLAKE2_Compress64_POWER8(const byte*, CryptoPP::BLAKE2b_State&)':
/home/noloader/cryptopp/blake2b_simd.cpp:1129:47: error: invalid parameter combination for AltiVec intrinsic
     #define vec_ror_32(x) vec_rl(x, ROR32_MASK)

Fortunately, we have some test programs stashed away in TestPrograms. In fact we can test for almost all features on every platform we support. In this case we can accurately detect the availability:

$ c++ -mcpu=power8 -maltivec TestPrograms/test_ppc_power8.cxx    TestPrograms/test_ppc_power8.cxx: In function 'int main(int, char**)':
TestPrograms/test_ppc_power8.cxx:5:15: error: invalid parameter combination for AltiVec intrinsic
  z=vec_add(z,z);

I think we should be able to cutover cleanly based on my experience with GNUmakefile using the test programs.

Add PowerPC support for GCC and XLC

This is a big addition... track it.