Link error VS.2003 MFC appHi, Brian. Sorry for the late reply, but I didn't see your original request. I'm using CryptoPP in an MFC app, compiling under WinXP Pro with VC .NET on one machine and WinXP Home with .NET 2003 on a notebook.
I remember having the link errors that appeared to come from std::string, but don't remember exactly what I did to cure them... I think the following three lines cured one problem, though: #include "crpp.h" using namespace CryptoPP; USING_NAMESPACE(std) "crpp.h" is just a list of CryptoPP header files to include in my project. "using namespace CryptoPP" just keeps me from having to put the qualifier in front of every CryptoPP function I call. The macro "USING_NAMESPACE(std)" might be what stopped the link errors. I also remember having a problem with CStrings relating to them being shared classes with ATL in .NET. It appears that they might behave like std::strings some (or all) of the time. I do remember doing a "Find in files" on CString and putting an "A" at the end to make it CStringA. I think that's what eliminated the linking errors I was getting that were similiar to the ones you're getting. That forces it to be an ASCII string instead of Unicode, too, and keeps me from having to deal with converting from ASCII to Unicode or back when sending messages from Win9x/Me machines to XP/NT machines. Note that in the .NET help files, the MFC Library Reference to MFC Classes does NOT include CString in the list, but does include CStringList and CStringArray... must be a reason for that. If you haven't already, you'll want to look at "TN033: DLL Version of MFC" in the help files or at MSDN web site. It addresses issues with using your DLL with an MFC app. MFC DLLs get memory (new or alloc) from the App's address space, but regular DLLs don't. That can cause problems when allocating memory in the app and freeing it in the DLL, and vice versa, when using MFC apps with non-MFC DLLs. Don't pass CStrings to ciphers for outputs, embedded NULL characters in the ciphertext will cause mysterious truncation of it (in the CString) some, but not all, of the time. Some CString functions (and I think some std::string functions) call C functions that use a zero byte to determine when they've reached the end of a string. Every once in a while a character in the input string will encrypt to a zero byte... that's normal. You probably won't have to modify the CryptoPP library at all to use it, and if I can make it work anyone should be able to. It's also really unusual to not get a reply here pretty quickly when someone has a question. So look carefully at the three Validate files and the test.cpp file, you'll find most of what you need there. Hope this helps, Rick ----- Original Message ----- From: Brian Smith To: '[EMAIL PROTECTED]' Sent: Thursday, September 18, 2003 11:41 AM Subject: RE: Link error VS.2003 MFC app Has anyone actually used the Crypto++ library in an MFC application? Barring that, how about making a DLL? My goal is to be able to use it (without great modification) in MFC applications and/or .NET applications. Currently, I'm using RSAREF code hand translated from C to C#, which works. However, I'd prefer to use the Crypto++ library with it's larger assortment of algorithms, more attractive license scheme, and more active development group. I hope to at least get a reply this time. Thanks in advance, Brian -----Original Message----- From: Brian Smith [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 13:34 To: '[EMAIL PROTECTED]' Subject: Link error VS.2003 MFC app I am attempting to use the latest version of Crypto++ (version 5.1) in Visual Studio.NET 2003 and the link stage emits many errors. The test sample (a console app) works just fine, fortunately. I get many many unresolved external symbols such as this: Linking... cryptlibd.lib(iterhash.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED] Z) cryptlibd.lib(pssr.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" ([EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@[EMAIL PROTECTED] Z) referenced in function "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl std::operator+<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,char const *)" ([EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@1@@std@@[EMAIL PROTECTED] [EMAIL PROTECTED]@std@@[EMAIL PROTECTED]@2@@[EMAIL PROTECTED]@[EMAIL PROTECTED]) Now, for more details, I just created a new VS.NET MFC C++ dialog based project (including the socket libraries) and tried to add the following function: #include "crypto++/osrng.h" #include "crypto++/rsa.h" void CCryptSetupDlg::OnBnClickedGenerateKey() { CryptoPP::AutoSeededRandomPool rng; CryptoPP::InvertibleRSAFunction privKey; privKey.Initialize(rng, 1024); } I did look at the FAQ and check the runtime libraries, the calling conventions and I checked to ensure that the VS.NET 2003 patch was applied. Anyone else use MFC with Crypto++ 5.1 ? I have a feeling that I'm missing something very simple and easy... Thanks in advance, Brian Smith
