mainwindow.obj:-1: error: LNK2001: unresolved external symbol "public: virtual unsigned __int64 __thiscall CryptoPP::ThreadUserTimer::GetCurrentTimerValue(void)" (?GetCurrentTimerValue@ThreadUserTimer@CryptoPP@@UAE_KXZ)
mainwindow.obj:-1: error: LNK2001: unresolved external symbol "public: virtual unsigned __int64 __thiscall CryptoPP::ThreadUserTimer::TicksPerSecond(void)" (?TicksPerSecond@ThreadUserTimer@CryptoPP@@UAE_KXZ)
mainwindow.obj:-1: error: LNK2019: unresolved external symbol "class CryptoPP::NameValuePairs const & const CryptoPP::g_nullNameValuePairs" (?g_nullNameValuePairs@CryptoPP@@3ABVNameValuePairs@1@B) referenced in function "public: __thiscall CryptoPP::HMAC::HMAC(unsigned char const *,unsigned int)" (??0?$HMAC@VSHA256@CryptoPP@@@CryptoPP@@QAE@PBEI@Z)
If you look at the source code for hrtimer.h, ThreadUserTimer is missing CRYPTOPP_DLL. That means the DLL does not export ThreadUserTimer (and many other classes).
In general, you should avoid the FIPS DLL unless you have a hard requirement to do so. Its special purpose, and its not easy to work with. It also has Operational Environment requirements from FIPS 140-2. I doubt you want to limit yourself to Visual Studio 2005 and Windows Server 2003.
If you insist on using the FIPS DLL, then you need to link against the DLL as expected. "As expected" means you use the cryptopp.lib import library at compile/link time; and cryptopp.dll at runtime. You also have to link again cryptlib.lib to get the missing classes, like ThreadUserTimer, while setting CRYPTOPP_IMPORTS to avoid duplicate symbols when using both libraries.
Instead of using the DLL, download the updated (and fixed) vs2010-dynamic.zip. Use it to build the Crypto++ library and then use the static library. "Use the static library" means to link against cryptlib.lib only.
The project files from vs2010-dynamic.zip might reference some source files that you don't have because its built from the latest stable sources. If the source file is missing, then simply delete it from the project file. Off the top of my head, Crypto++ 5.6.2 should be missing HKDF, RDRAND, RDSEED, ChaCha, BLAKE2, Base64URLEncoder, Base64URLDecoder, etc. It also lacks the rename of bench.cpp to bench1.cpp.
The Visual Studio wiki page has more information on Windows project files and artifacts like cryptlib.lib.
INCLUDEPATH += ".../cryptopp562/include"
LIBS += -L"...\cryptopp562\include\cryptopp\Win32\DLL_Output\Release" -lcryptopp
I think you should use only -lcryptlib because its the static library, and it has everything you need. The path to the library is $(Platform)\Output\$(Configuration), but I don't know how to translate it into something QT composer can use.
Otherwise, I think you need to specify both -lcryptopp -lcryptlib, and add CRYPTOPP_IMPORTS to preprocessor definitions.
vs2010.zip, vs2010-dynamic.zip and vs2005-dynamic.zip are built from the latest GitHub sources. As of this writing (JUN 1 2016), that's effectively pre-Crypto++ 5.6.4. If you are using the ZIP files with a down level Crypto++, like 5.6.2 or 5.6.3, then you will run into minor problems.
There are two minor problems I am aware. First is a rename of bench.cpp to bench1.cpp. Its error is either:
C1083: Cannot open source file: 'bench1.cpp': No such file or directoryLNK2001: unresolved external symbol "void __cdecl OutputResultOperations(char const *,char const *,bool,unsigned long,double)" (?OutputResultOperations@@YAXPBD0_NKN@Z)
The fix is to either (1) open cryptest.vcxproj in notepad, find bench1.cpp, and then rename it to bench.cpp. Or (2) rename bench.cpp to bench1.cpp on the filesystem.
The second problem is a little trickier because its a moving target. Down level releases, like 5.6.2 or 5.6.3, are missing the latest classes available in GitHub. They include HKDF (5.6.3), RDRAND (5.6.3), RDSEED (5.6.3), ChaCha (5.6.4), BLAKE2 (5.6.4), Poly1305 (5.6.4), etc.
The fix is to remove the missing source files from the Visual Studio project files since they don't exist for the down level releases.
Another option is to add the missing class files from the latest sources, but there could be complications. For example, many of the sources subtly depend upon the latest config.h, cpu.h and cpu.cpp. The "subtlety" is you won't realize you are getting an under-performing class.
An example of under-performing class is BLAKE2. config.h adds compile time ARM-32 and ARM-64 detection. cpu.h and cpu.cpp adds runtime ARM instruction detection. If you add BLAKE2 without the other files, then none of the detection occurs and you get a straight C/C++ implementation. The NEON implementation runs around 9 to 12 cycles per byte, while the C/C++ implementation runs around 40 cycles per byte.
