Linker errors on 7.0
Hello,
I develop a C++ library and I deliver it to other parties as a static library (It links to Multithread-DLL runtime library. ). The library is built on VC++ 7.1.
I have a customer who tried to use the library on VC++ 7.0. He got linker errors, such as :
Test error LNK2001: unresolved external symbol "__declspec(dllimport) ?$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z" (__imp_?$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z)Test error LNK2001: unresolved external symbol "__declspec(dllimport) ?$?9DU?$char_traits@D@std@@V?$allocator@D@1@@std@@YA_NABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@PBD@Z" (__imp_?$?9DU?$char_traits@D@std@@V?$allocator@D@1@@std@@YA_NABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@PBD@Z) Could anybody make a guess what's wrong here ?
Thanks,
Devrim.
[996 byte] By [
mderdem] at [2007-12-16]
I suspect that the underlying reason for this failure is that we made a lot of fixes in Visual C++ 7.1 to make the compiler and the associated C++ runtime much more conformant to the C++ Standard. Some of these changes required that we make some changes to the algorithm we use to generated decorated names. The fact that the linker errors your customer is seeing contain only decorated names seems to imply that the 7.0 linker that they are using cannot understand these names and hence they have changed.
The decorated names are referring to the following symbols:
"bool __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 *)"
"class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl std::operator<<<struct std::char_traits<char> >(class std::basic_ostream<char,struct std::char_traits<char> > &,char const *)"
The specific problem here is that you have a static library built with the 7.1 compiler and that library references the 7.1 version of the C++ runtime. Your customer is then taking this static library and attempting to link it into their application: but as they are using the 7.0 version of the C++ runtime it is failing to link as the names of some of the symbols have changed (as I have outlined above).
Note: that even if the names hadn't changed mixing 7.0 and 7.1 versions of the C++ runtime like this is dangerous as the size of some of the underlying structures may have changed and thus the code could fail at runtime.
If you do need to support customers who are still using the 7.0 compiler/runtime then I would suggest that you statically link your library to the 7.1 version of that C++ runtime: this will ensure that your library is completely standalone.
Thanks Jonathan, I understand the problem better now.
We may also ship DLLs instead of static libraries. Would this allow us to avoid problems with 7.0 using customers ? To my understand the same problem would occur as the DLL is compiled against the 7.1 C++ runtime.
Is that correct ?
Thanks,
Hi Jonathan.
I am having a similar issue. I got source code of something that was written in Visual C++ 6.0, and trying to get it working in the very latest Visual C++ 8.0. I am getting the link errors below.
libagtkitd.lib(mgkgenercol.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) bool __cdecl std::operator==(class std::basic_string,class std::allocator > const &,char const *)" (__imp_?8std@@YA_NABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@PBD@Z)
libagtkitd.lib(mgkmomgr.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) bool __cdecl std::operator==(class std::basic_string,class std::allocator > const &,char const *)" (__imp_?8std@@YA_NABV?$basic_string@DU?
You suggest in your message to "statically link your library to the 7.1 version of that C++ runtime:". How do I do that? Any hints will be appriciated! Thank you.
