Why would a .lib compiled in VS2003 fail to link with code compiled with VS2008?

Question

We just had an interesting experience in trying to link a set of code compiled using Visual Studio Express 2008 with a .lib compiled with Visual Studio 2003. All in C++. To be precise, it was the SystemC 2.2.0 kernel that was compiled in VS2003 into a .lib, and a SystemC model which was compiled in VS2008.

When linking, we kept getting the error that a few symbols from the SystemC.lib file (i.e., compiled in VS2003) were not found during linking. The error we get getting was this (in a few variants):

SystemC.lib(sc_port.obj) : error LNK2001: unresolved external symbol "public: vo
id __thiscall std::_String_base::_Xran(void)const " (?_Xran@_String_base@std@@QB
EXXZ)

Digging on from various leads, it turned out that the function the .lib expected to find was this:

Undecoration of :- "?_Xran@_String_base@std@@QBEXXZ"
is :- "public: void __thiscall std::_String_base::_Xran(void)const "

While the library file that VS2008 was trying to link with (libcpmt.lib) used a different calling convention:

Undecoration of :- "?_Xran@_String_base@std@@SAXXZ"
is :- "public: static void __cdecl std::_String_base::_Xran(void)"

I tried to figure out why this incompatibility happened, but in the end I gave up, recompiled the exact same visual studio project in VS2008, and used that SystemC.lib instead of the one from VS2003. Now, things worked perfectly.

So the fundamental question here is: what has changed from VS2003 to VS2008 that would cause some functions to change their calling conventions? And is there some magic flag to give to the linker in VS2008 to use some other library where the functions have the same calling convention as in the VS2003 compile?

Update, summary of answers so far: It is very likely that Microsoft changes the C++ (not C, just C++) ABI from one major version of Visual Studio to the next. There can also be other changes in the libraries that cause incompatibilities. The best advice is to recompile the .lib for each version of VS. Essentially, just ship it in source to the users and have them compile it locally using whatever version of VS they happen to have installed.

The basic issue was discovered by using the advice in:

• http://stackoverflow.com/questions/261377/lnk2001-error-when-compiling-apps-referencing-stlport-5-1-4-with-vc-2008

Note that these questions did not answer this issue:

• http://stackoverflow.com/questions/651198/can-you-create-a-lib-or-dll-in-vs-2005-and-link-with-vs-2008

Answer 1

There is no standard for the C++ ABI. Which means that all the c++ compiler could handle a different ABI from one to the other, and that includes different version from the same compiler. You could have the same issue with 2 different major release from Gcc. Such modification could happen when they find a way to improve linking step.

But ABI involve much more that that. For instance the way vtable are stored and handle behind the hood by the code generated by the compiler. If it changes, your objects and your code generated in 2008 won't be compatible with the library expecting the way it is done in 2003.

At this point you could understand why c++ libraries are either shipped with their source code or shipped compiled on many different architecture and compilers.

Usually when writing a library, in order to avoid such issues, you develop it in C langage, not c++. As C comes with a standardised ABI, you are able to compile it with one compiler and then link that library with any C compiler wich respect that C ABI standard. For instance the way character string is implemented is standard and will probably never move (the infamous null terminated string). While std::string implementation changes from one Gcc major release to the other (just have a look in the basic_string class from /usr/include/c++/x.x/bits/basic_string files)

Answer 2

As far as I know these problems happen because of the CRT library, they change with major releases and you shouldn't mix CRT types(multi-threaded, debug, release, static, dynamic, etc).

Usually they can be minimized by linking dynamically with CRT, I had success reusing VS2003 libraries in VS2005 but it's annoying, it's better to just recompile the whole thing. Sometimes you can get away by using the /NODEFAULTLIB compiler flag to avoid linking with a certain CRT library that's causing problems.