LNK2005 Error: basic_string already defined
-
WendyS56 wrote:
In the exports table the functions (e.g. resize) that the linker complains about are external and prefixed with __imp_. Is this why the linker is complaining?
No - that's correct linkage to a function defined in a DLL.
WendyS56 wrote:
What is the difference between these two?
The first replaces
std_stringbystringand relies on the using (not #using, I believe) statement to make string resolve to std::string. The second just replacesstd_stringbystd::string. BTW - can you post the exact text of the LNK2005 message?Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Here are a few of the linker errors (ciwsgif is my application): msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct>,class std::allocator >::basic_string<char,struct>,class std::allocator >(void)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in ciwsgif.obj msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct>,class std::allocator >::basic_string<char,struct>,class std::allocator >(class std::basic_string<char,struct>,class std::allocator > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in ciwsgif.obj msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct>,class std::allocator >::basic_string<char,struct>,class std::allocator >(char const *)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z) already defined in ciwsgif.obj
-
Here are a few of the linker errors (ciwsgif is my application): msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct>,class std::allocator >::basic_string<char,struct>,class std::allocator >(void)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in ciwsgif.obj msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct>,class std::allocator >::basic_string<char,struct>,class std::allocator >(class std::basic_string<char,struct>,class std::allocator > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in ciwsgif.obj msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string<char,struct>,class std::allocator >::basic_string<char,struct>,class std::allocator >(char const *)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z) already defined in ciwsgif.obj
WendyS56 wrote:
already defined in ciwsgif.obj
I'm presuming
ciwsgif.cppis in one of your libraries?Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
WendyS56 wrote:
already defined in ciwsgif.obj
I'm presuming
ciwsgif.cppis in one of your libraries?Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Yes, ciwsgif is my main application file which uses the 4 libraries. It includes , and along with some header files corresponding to the 4 libraries.
-
Yes, ciwsgif is my main application file which uses the 4 libraries. It includes , and along with some header files corresponding to the 4 libraries.
Well...that's where the conflicting definitions are coming from
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Well...that's where the conflicting definitions are coming from
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Do you mean if my application includes "string.h" and some other library header files include "string" or "CString" then there would be a conflict? Or is it because there are multiple includes of the same header file (i.e. string.h)?
-
Do you mean if my application includes "string.h" and some other library header files include "string" or "CString" then there would be a conflict? Or is it because there are multiple includes of the same header file (i.e. string.h)?
WendyS56 wrote:
Do you mean if my application includes "string.h" and some other library header files include "string" or "CString" then there would be a conflict? Or is it because there are multiple includes of the same header file (i.e. string.h)?
No - multiple includes shouldn't do that. What that message is saying is that your main object contains definitions for the string methods. I'm not sure why, but that's what the message is saying.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
WendyS56 wrote:
Do you mean if my application includes "string.h" and some other library header files include "string" or "CString" then there would be a conflict? Or is it because there are multiple includes of the same header file (i.e. string.h)?
No - multiple includes shouldn't do that. What that message is saying is that your main object contains definitions for the string methods. I'm not sure why, but that's what the message is saying.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Thank you for clarifying things for me :) When running dumpbin and looking at all the EXPORTS, basic_string is EXPORT'ed from lib4. I understand that to mean that these functions are made available by that library. Am I correct? Would it make a difference to dynamically link my application to the libraries rather than statically linking to the .libs?
-
Thank you for clarifying things for me :) When running dumpbin and looking at all the EXPORTS, basic_string is EXPORT'ed from lib4. I understand that to mean that these functions are made available by that library. Am I correct? Would it make a difference to dynamically link my application to the libraries rather than statically linking to the .libs?
WendyS56 wrote:
Would it make a difference to dynamically link my application to the libraries rather than statically linking to the .libs?
Could well do - with DLLs, you explicitly specify what is exported, whereas with static libraries, there's less control over what is visible from the library.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
WendyS56 wrote:
Would it make a difference to dynamically link my application to the libraries rather than statically linking to the .libs?
Could well do - with DLLs, you explicitly specify what is exported, whereas with static libraries, there's less control over what is visible from the library.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
My program compiles and links successfully now :laugh: I used dynamic linking to lib4. I then needed to remove the NODEFAULTLIB:"libcpmt.lib and NODEFAULTLIB:"libc.lib" from my application link options. (I still needed to have NODEFAULTLIB:"libcmt.lib") Thank you for your help!
-
My program compiles and links successfully now :laugh: I used dynamic linking to lib4. I then needed to remove the NODEFAULTLIB:"libcpmt.lib and NODEFAULTLIB:"libc.lib" from my application link options. (I still needed to have NODEFAULTLIB:"libcmt.lib") Thank you for your help!
WendyS56 wrote:
My program compiles and links successfully now
Excellent! That wasn't so difficult now, was it :~ :-D
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p