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
Related
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 MFC projects.
A library project uses Multi-byte Character set.
An executable project uses Unicode Character set.
I only wrote the library project and have to use it in the executable.
One of the library's functions returns a CString.
When I try to put that CString into a variable in my unicode project and compile
I get this:
Error 3 error LNK2001: unresolved external symbol "public: class
ATL::CStringT<wchar_t,class StrTraitMFC_DLL<wchar_t,class
ATL::ChTraitsCRT<wchar_t> > > __thiscall CTextDisplay::GetString(void)"
(?GetString#CTextDisplay##QAE?AV?$CStringT#_WV? $StrTraitMFC_DLL#_WV?
$ChTraitsCRT#_W#ATL#####ATL##XZ)
I don't mind converting on any of the projects. I just want a way for the library to be able to return a string to the executable project.
Switching either project to the other character set is not an option as they are both gigantic.
Thanks in advance.
There is really no such thing as returning a CString. There are CStringA's and CStringW's and it sounds like you are receiving one and want the other. You will need to use MultiByteToWideChar and/or WideCharToMultiByte to convert.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd319072(v=vs.85).aspx
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.
I am using a library of code from a tutorial for providing functionality for passing function points of non-static member functions to a function that expects a static function pointer, probably helps to know what I am suing, so here is the link http://www.codeproject.com/KB/cpp/thunk32.aspx This code uses the Boost library, which I have downloaded and set-up more or less everything from.
In the Thunk library, one of the header files has a section that reads
#define BOOST_PP_ITERATION_PARAMS_1 (3,(0,THUNK32_MAX_ARGS,"Thunk32_template.h"))
??=include BOOST_PP_ITERATE()
#undef BOOST_PP_ITERATION_PARAMS_1
but this gives me epic amounts of errors, which I can solve by changing it to
#define BOOST_PP_ITERATION_PARAMS_1 (3,(0,THUNK32_MAX_ARGS,"Thunk32_template.h"))
#include BOOST_PP_ITERATE()
#undef BOOST_PP_ITERATION_PARAMS_1
This code that is downloaded is included in my solution as a second project, which is able to compile and build happily. But my project that is using this code has issues linking, to save people asking, I get these error messages
1>WebCamera.obj : error LNK2019: unresolved external symbol "protected: __thiscall indev::Thunk32Base::Thunk32Base(void)" (??0Thunk32Base#indev##IAE#XZ) referenced in function "public: __thiscall indev::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>(void)" (??0?$Thunk32#VWebCamera##$$A6AXPAUHWND__##PAUvideohdr_tag###Z#indev##QAE#XZ)
1>WebCamera.obj : error LNK2019: unresolved external symbol "protected: __thiscall indev::Thunk32Base::~Thunk32Base(void)" (??1Thunk32Base#indev##IAE#XZ) referenced in function "public: __thiscall indev::Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>::~Thunk32<class WebCamera,void __cdecl(struct HWND__ *,struct videohdr_tag *)>(void)" (??1?$Thunk32#VWebCamera##$$A6AXPAUHWND__##PAUvideohdr_tag###Z#indev##QAE#XZ)
1>WebCamera.obj : error LNK2019: unresolved external symbol _capCreateCaptureWindowA#32 referenced in function "public: bool __thiscall WebCamera::Init(struct HWND__ *)" (?Init#WebCamera##QAE_NPAUHWND__###Z)
I think this is trying to say that the constructor and destructor are not declared and that my WebCamera.Init()is messed up as well. I have made sure that the library that the Thunk32 project exports is included in my other project, but still I get these errors.
I would like to know if I have made the correct assumption that ??=include should have been changed to #include and if I have, what have I done wrong or failed to do that results in these linker errors. Or if you can provide me with a different way of being able to pass a function pointer to a non-static member function that would be awesome.
Thanks
??= is a "trigraph" sequence for the # character. according to the standard, trigraphs are supposed to be handled as one of the first steps in processing (in phase 1 - before the preprocessor handles directives),so:
??=include "whatever"
Should be equivalent to:
#include "whatever"
so you should be able to use that form (I wonder why the trigraph was put there in the first place - some sort of evil joke perhaps?)
However, trigraphs cause problems and confusion (probably more than they help), so compilers seem to be moving towards warning about them and/or defaulting to not handling them. The compiler in VS 2010 has trigraph processing turned off by default - you have to use the /Zc:trigraphs option to turn it on.
See Purpose of Trigraph sequences in C++? for more details.
Ah, Einar, good man. Doing flash and Sharepoint stuff these days, ouch. Norwegian, might explain the trigraphs.
Anyhoo, nothing complicated, you just forgot to tell the linker to look at some libraries. Right-click your project, Project Dependencies, tick the Thunk project. That makes sure that Thunk32.lib gets looked at and resolves the ctor and dtor.
Right-click again, Properties, Linker, Additional dependencies, add "winmm.lib". That resolves the capCreateCaptureWindow symbol.
Do you have a constructor and a destructor declared in the indev::Thunk32Base class that you forgot to define in its cpp file?
Ok, so I have managed to solve this now.
Michael Burr nicley said that ??= is basically the same as typing # but in a way that people who dont have the hash symbol can type it, see Purpose of Trigraph sequences in C++?
Hans Passant then got the ball rolling for me buy letting me know that I had not fully linked in stuff. I needed to right click on my main project, select 'Project Dependencies' and select my other project that has the thunk32 code. I also needed to tell my main project to look at where the Thunk project is saving the lib, which turned out to be in a folder in my documents (explain that one!). I also needed to add the Thunk32d.lib (note the 'd' because I was/am in debug mode. Hans said that I needed winmm.lib but it turned out (when googling the function that was giving me the error that I needed Vfw32.lib instead.
Thanks guys! I hope that by giving the full answer like this it can help some one else who has a similar problem.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is an undefined reference/unresolved external symbol error and how do I fix it?
I am working on wrapping a large number of .h and .lib files from native C++ to Managed C++ for eventual use as a referenced .dll in C#.
I have the .lib files linked in and everything has been going smoothly so far. Upon wrapping the latest .h file, I hit a snag when 2 functions came back with the link error:
error LNK2019: unresolved external symbol __imp__htonl#4 referenced in function
"public: void __thiscall Field::setCharacter(unsigned char,int)"
(?setCharacter#Field##QAEXEH#Z) myutils.lib
I have referenced myutils.lib in the linker options, so that shouldn't be the issue.
What's strange is that I have about 20 functions in this particular .h file and all of the rest are linking just fine except for 3 functions.
Any ideas?
The missing symbol is __imp__htonl#4, which is a C++ mangled name for htonl, which is a function that converts a long value from host to network order. The #4 is used to mangle the input parameters and is part of C++ support for overloaded functions to allow the linker to resolve the right function w/o name collisions.
Make sure that you are linked to the network library that you are referencing this symbol from. Presumably your package is using some special definition of this symbol, instead of the MACRO that it usually is.
Are you sure the signatures match? Be sure to checked for signed-ness and const-ness. Also, make sure functions aren't inlined.
I ran into this error when I compiled against a library and then changed the library before linking. Make sure your headers are the same ones provided by your library (not copied from another architecture, etc). Of course, make sure you're linking against ws2_32.lib (-lws2_32 for mingw/gcc).
Additionally, if you are using GCC/mingw you may want to take a look at this: MinGW linker error: winsock