I'm trying to write some simple test code for the Crypto++ library for a project. I have yet to manage to get my own code to build though. It compiles fine, the problem comes in linking. I'm still pretty new to Visual Studios, but I'm using VS10. The errors I'm getting are:
1>sec_test.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CryptoPP::DES::Base::ProcessAndXorBlock(unsigned char const *,unsigned char const *,unsigned char *)const " (?ProcessAndXorBlock#Base#DES#CryptoPP##UBEXPBE0PAE#Z)
1>sec_test.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall CryptoPP::DES::Base::UncheckedSetKey(unsigned char const *,unsigned int,class CryptoPP::NameValuePairs const &)" (?UncheckedSetKey#Base#DES#CryptoPP##UAEXPBEIABVNameValuePairs#3##Z)
I've tried everything I can find in the documentation in terms of linking. I've never linked against a DLL before, but these are the errors I get when I try to. If I try to do what I think is linking against the static library version, I get even more.
I should note, I'm trying to test pure DES at the moment. In particular, here are the API calls I'm making, just to be safe:
DES::Encryption DES_encrypt;
DES_encrypt.SetKey(key, 64);
DES_encrypt.ProcessAndXorBlock(plaintext, NULL, ciphertext);
DES::Decryption DES_decrypt;
DES_decrypt.SetKey(key, 64);
DES_decrypt.ProcessAndXorBlock(ciphertext, NULL, decrypted);
If anyone can help, or point me in the right direction, I'd be much obliged.
First thing to check is your project properties (right click on project, click Properties).
External libraries need to be specified in the Linker->Input->Additional Dependencies field, either by absolute path or in conjunction with the other VS path properties.
You can look in Linker->Command Line and check that the .lib files you want are actually being passed to the linker.
An alternate method is to turn off the Suppress Startup Banner option in the Linker->General options, and then check the build output to make sure it has what you want.
If you know that the libraries you want are being linked, another useful trick is to check the output of the strings command (in linux or cygwin) or dumpbin /HEADERS in the VS command prompt. You can look through the output of these commands for the symbol VS claims is missing to verify that it really is defined in the .lib file. Sometimes larger software packages have multiple .lib files, so this can help make sure you are linking the one that has the symbol you want.
Related
I am trying to get protocol buffer to work but linking problems occurs.
All the errors looks something along like this
error LNK2019: unresolved external symbol "public: bool __cdecl google::protobuf::MessageLite::ParseFromArray(void const *,int)" (?ParseFromArray#MessageLite#protobuf#google##QEAA_NPEBXH#Z) referenced in function "void __cdecl ReceiveRequest(bool *)" (?ReceiveRequest##YAXPEA_N#Z)
I am using visual studio pro 2013 and this is what I have done:
I compiled the protocol buffer and added the libprotobuf.lib to the project(Add->Existing Item->libprotobuf.lib)
I've added the header files in C/C++ -> General -> "Additional Include Directories"
I have tried to add the library all the different ways I know but I still get these linking errors...
Any idea what I might have done wrong?
// Eric
You need to include the generated protocol buffer .cc (and maybe the .h) file (ie the file with the specific getters and setters for your specific proto) in your VS project (ie there has to be a little icon for them in the solution explorer) or else visual studio won't generate the code for it and thus there's nothing to link to.
Make sure you have the correct libraries for your architecture (e.g. x86 / x64).
That has caught me out a few times.
I am trying to solve the following issue: I've got a library which uses C++Amp. The library compiles without any warnings and the unit-tests indicate that everything is working. I have a QT-based project which is a GUI for this library and here the problems begin. Everytime I am compiling the GUI, in the linking stage a get the following errors:
widgets.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) private: unsigned short const * __cdecl Concurrency::accelerator::_Get_device_path(void)const " (_imp?_Get_device_path#accelerator#Concurrency##AEBAPEBGXZ) referenced in function "void __cdecl `dynamic initializer for 'public: static class std::_Future_error_category std::_Future_error_object::_Future_object''(void)" (??__E?_Future_object#?$_Future_error_object#H#std##2V_Future_error_category#2#A##YAXXZ)
The library is linked to lib file, not dll.
Same story goes for other object files in the project. Did anyone have a similar problem at the linking stage when using C++Amp. I am sure that it is a very simple problem to solve but at the moment I have no idea how I could do it. Thanks in advance.
Update: the same happens when I am trying to include in the QT project in MSVC++.
__imp_?_Get_device_path#accelerator#Concurrency##AEBAPEBGXZ
Running the undname.exe utility on that string to unmangle the name, I get:
declspec(dllimport) private:
unsigned short const * __ptr64
__cdecl Concurrency::accelerator::_Get_device_path(void)const __ptr64
So it is 64-bit code. Looking in vc/lib/amd64/vcamp.lib for a closest match, I find:
?_Get_device_path#accelerator#Concurrency##AEBAPEB_WXZ
Which demangles with undname.exe to:
private:
wchar_t const * __ptr64
__cdecl Concurrency::accelerator::_Get_device_path(void)const __ptr64
Note the discrepancy. Your function got compiled to return unsigned short*, the library function returns wchar_t*. You have a compiler setting wrong. Project + Properties, C/C++, Language, Treat WChar_t As Built in Type must be set to the default, "Yes".
I'm new to MFC.
I'm trying to make a DLL in MFC, which links to another DLL.
The problem is when I try and compile, I get a LNK2019 error thrown at me for a function present in the DLL which I'm trying to link.
LNK2019 is when the DLL or the function inside the DLL is not being found.
I've taken all steps, the DLL is placed in a known location, the lib is placed in a known location too, it's been added in the additional dependencies, all correct switches have been applied ( ones I know of anyway ).
I've used Dependency walker and I know the DLL, to which I'm trying to link, exposes this function.
I've other examples of use of the function, and I'm trying to use it exactly like it.
The .lib and .dll are in agreement, i.e., they're consistent with each other.
But still the error persists.
EDIT
This is the error message :
Error 2 error LNK2019: unresolved external symbol
"__declspec(dllimport) public: bool __thiscall
PwServer::Connect(wchar_t const *,unsigned long,unsigned long *)"
(_imp?Connect#PwServer##QAE_NPB_WKPAK#Z) referenced in function
"public: bool __thiscall CPwServer::Connect(class
ATL::CStringT > >,unsigned long,unsigned long *)"
(?Connect#CPwServer##QAE_NV?$CStringT#_WV?$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL##KPAK#Z)
And this is the call I use to access the DLL.
bool conn = PwSrv->Connect(_T(""));
Dumpbin Export of the function :
25BE6 ?Connect#PwServer##QAE_NPBGKPAK#Z 25BE6 __imp_?Connect#PwServer##QAE_NPBGKPAK#Z
Is there something else which needs to be dine in case of linking a MFC DLL with a regular one, like adding AFX_EXT_ or something?
Kindly advise in this.
Thank you.
UPDATE
Seems all that was required was to toggle the flag set in Project Properties>>C/C++>>Language>>Treat wchar_t as a built in type to NO. I'd never bothered with the flag before, so didn't know. The Linker error was there...
OK. Now I've another problem. The toggling of wchar_t solved the problem of the DLL linking with another MFC DLL, but now my application cannot find the entry point in my DLL. In dependency walker, it shows a mismatch between CString which the application is sending, and the Unsigned Short..which my DLL is accepting ( as a result of thewchar_t turned off, presumably )
Assuming you correctly included the .lib file for the DLL (most of the time this is down to differences in the compiler settings. e.g. UNICODE setting).
Check that the .lib is actually being loaded by setting the 'Show Progress' Linker settings to VERBOSE.
Run DUMPBIN on the LIB file to check that the exported functions are the same as the ones the linker is trying to import.
ie
dumpbin /ALL mylib.lib > exports.txt
If the name decoration is slightly different that'll give you a clue as to the problem.
I have 2 projects in c++ (MFC)
One is a library project which im using in the second one (an executable one).
They work together great, until I call a function from the regular project that takes a CString as argument. I get a linker error like this
error LNK2019: unresolved external symbol "public: void __thiscall
CTextDisplay::SetText1(class ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,
class ATL::ChTraitsCRT<wchar_t> > >)" (?SetText1#CTextDisplay##QAEXV?$CStringT#_WV?
$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL###Z) referenced in function
"public: void __thiscall CManualPane::SetBeadCountFor(int,double)"
(?SetBeadCountFor#CManualPane##QAEXHN#Z) C:\source\IQ-Project\IQ\ManualPane.obj IQ
The executable project has its character set to UNICODE but the Library has it set to Multy-Byte chatacter set. I really can't change them without getting ridiculous amounts of errors.
Any suggestions?
Edit: The reason we have different settings in these two projects is because the Executable project is basically an external project that my group didn't build or create. We just had to bring it in and use it. The library project is something we've all been working on for a couple years.
When you include the headers of the library project in the executable, there is likely a typedef which is used in the declaration of the function. Since the executable uses UNICODE, the declaration is now in UNICODE. However, the library implementation is still in MultiByte and so the definition doesn't match the declaration leading to the linker error.
Look into how these typedefs are being setup, and you might be able to do some special #define, #undef around the included header.
In the end it proved to be a better idea to avoid having unicode and multybyte projects in the same solution so I moved it all to unicode and went from there
I frequently have this problem when I try a new library. This time I work with PointGrey Camera and try to use its API libraries (some dll, lib, header files). Mostly, problems were fixed by configuring the SDK (I'm using VS2008) Tools/Options/VC++ Directories/include files(/library files)(/executable files),
I also tried with project configuration:
+ project properties/linker/input/additional dependencies
+ project properties/linker/General/Additional Library Directories
This time, with all this, I still have the error.
Is there a general method to deal with this problem?
do I need to understand this diagnosis from VS2008?
Error 1 error LNK2019: unresolved external symbol __imp__flycaptureGetPacketInfo referenced in function "enum FlyCaptureError __cdecl initializeStandardEventSizes(void *,struct FlyCaptureImageEvent * const)" (?initializeStandardEventSizes##YA?AW4FlyCaptureError##PAXQAUFlyCaptureImageEvent###Z) main_2.obj test
does using analysis tool such as Dependencies Walker ensure to solve these problems well??
This message says that you used a symbol (a function or a variable) in your code. This symbol was probably declared somewhere (most likely in a header file you included in your code) otherwise there would have been a compilation error. When the linker searched for the symbol (in both your object files and the lib files you instructed it to look in) it couldn't find it.
That usually happens because you forgot to let the linker know about a lib you want it to search in.
Most libraries come with a set of instruction that is supposed to help you set up everything correctly and avoid running into these problems.
This problem has been solved lately. I installed the incompatible library of PointGrey. That's why it didn't work. But this says something between "incompatible library" and "unresolved exertal symbol error"