Linker errors on 7.0

Linker errors on 7.0

• anna_uk

  Me too!!

  All I'm doing is to re-compile my code on latest Platform SDK (Beta release).

  and I get the same 'unresolved external symbol' errors

  Any suggestions

  Thanks in advance.

  
  

• lemmi

  If you redistributed the 7.1 C++ runtime DLL with your static library the problem I could forsee is that the user's application would now be using two different versions of the C++ runtime - the 7.0 version directly and the 7.1 version indirectly through your static library - this may work fine but you would want to ensure that memory allocation was handled correctly (specifically each memory allocation is allocated and freed by the same runtime) and that there are not any problems with both the 7.0 and 7.1 runtime competing for the console (and other unique resource).

  
  
  

• Ben Nevarez

  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,
  
  

• McPhisto77

  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.

  
  

• Nick Ericson - MSFT

  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.

   

  
  
  
• Linker errors on 7.0