CLion and Crypto++ library

Question

Some time ago I started coding my application in Visual Studio 2015, had no issues setting all of the library dependencies.

Now, I decided to move to CLion. However my application has a dependency of cryptopp library, which I need to link in my CLion project.

Currently, I'm facing tons of undefined reference errors

undefined reference to `CryptoPP::Integer::Integer(char const*)'
undefined reference to `CryptoPP::Integer::Integer(char const*)'
undefined reference to `CryptoPP::Integer::Integer(char const*)'
undefined reference to `CryptoPP::DH_Domain<CryptoPP::DL_GroupParameters_GFP_DefaultSafePrime, CryptoPP::EnumToType<CryptoPP::CofactorMultiplicationOption, 0> >::AccessGroupParameters()'
undefined reference to `CryptoPP::DH_Domain<CryptoPP::DL_GroupParameters_GFP_DefaultSafePrime, CryptoPP::EnumToType<CryptoPP::CofactorMultiplicationOption, 0> >::GetGroupParameters() const'
undefined reference to `CryptoPP::DH_Domain<CryptoPP::DL_GroupParameters_GFP_DefaultSafePrime, CryptoPP::EnumToType<CryptoPP::CofactorMultiplicationOption, 0> >::GetGroupParameters() const'
[..]

I have indeed set include directories in my CMakeLists:

set(EXTERN_LIBS E:/dev/libs)

include_directories(${EXTERN_LIBS} ${EXTERN_LIBS}/include)
link_directories(${EXTERN_LIBS})

However, I still cannot get it to work.

I'm using MinGW for my project. Here is a preview of settings and versions:

How can I properly add cryptopp library into my project in CLion?

Answer 1

I think we may have mostly cleared the MinGW/C++11 issue at Commit e4cef84883b2. You should work from Master or perform a git pull, and then uncomment the define for CRYPTOPP_NO_CXX11 in config.h : 65 (or so):

// Define CRYPTOPP_NO_CXX11 to avoid C++11 related features shown at the
// end of this file. Some compilers and standard C++ headers advertise C++11
// but they are really just C++03 with some additional C++11 headers and
// non-conforming classes. You might also consider `-std=c++03` or
// `-std=gnu++03`, but they are required options when building the library
// and all programs. CRYPTOPP_NO_CXX11 is probably easier to manage but it may
// cause -Wterminate warnings under GCC. MSVC++ has a similar warning.
// Also see https://github.com/weidai11/cryptopp/issues/529
// #define CRYPTOPP_NO_CXX11 1

I think the problems is, you are hitting issues related to Windows and its lack of proper C++11 support, but you are getting them indirectly. They are indirect because MinGW and GCC is layered on top. MinGW and GCC cannot possibly provide C++11 because the underlying platform cannot.

I think your best bet at this point is to define CRYPTOPP_NO_CXX11. I don't believe we can do it for you like we do on Windows because the defines we need access to are hidden behind MinGW and GCC. And we also have some MSVC++ bugs to workaround.

Here's how we do it on Windows, but we don't have access to these defines in MinGW (from config.h : 950):

// Dynamic Initialization and Destruction with Concurrency ("Magic Statics")
// MS at VS2015 with Vista (19.00); GCC at 4.3; LLVM Clang at 2.9; Apple Clang at 4.0; Intel 11.1; SunCC 5.13.
// Microsoft's implementation only works for Vista and above, so its further
// limited. http://connect.microsoft.com/VisualStudio/feedback/details/1789709
#if (CRYPTOPP_MSC_VERSION >= 1900) && ((WINVER >= 0x0600) || (_WIN32_WINNT >= 0x0600)) || \
    (CRYPTOPP_LLVM_CLANG_VERSION >= 20900) || (CRYPTOPP_APPLE_CLANG_VERSION >= 40000) || \
    (__INTEL_COMPILER >= 1110) || (CRYPTOPP_GCC_VERSION >= 40300) || (__SUNPRO_CC >= 0x5130)
# define CRYPTOPP_CXX11_DYNAMIC_INIT 1
#endif // Dynamic Initialization compilers

If you define CRYPTOPP_NO_CXX11, then the following will not be defined and you will avoid the problems: CRYPTOPP_CXX11_DYNAMIC_INIT, CRYPTOPP_CXX11_SYNCHRONIZATION, and CRYPTOPP_CXX11_ATOMICS.

---

The second issue, the one related to Clion and Cmake, was settled as follows. We setup a separate GitHub with our Autotools and Cmake files. The Autotools files are at cryptopp-autotools, and the Cmake files are at cryptopp-cmake.

The repositories are in my GiHub because this is the sort of administrivia that Wei Dai, who wrote the library and provides the Crypto++ GitHub, prefers to avoid. The logical separation also helps establish the logical boundary so folks know Autotools and CMake are not part of the official Crypto++ distribution.

The community is responsible for Autotools and Cmake, and we will work with the community on issues. If the community puts in the work, then Autotools and Cmake will improve. If either Autotools or CMake gets stable, then we will add a tarball with the files to the official distribution.

Currently Autotools and Cmake are in states that needs improvement. The problems with Cmake are detailed at CMake | Current Status on the wiki. The problems with Autotools are not really documented because I work with distro maintainers on them. Its kind of like we know what the prolems are, but most others do not.