Geek Answers Handbook

Why is the .lib compilation in VS2003 not related to the code compiled with VS2008?

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

When linking, we continued to get the error that several characters from the SystemC.lib file (i.e., compiled in VS2003) were not found during linking. The error we get was this (in several ways):

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 from various potential customers, it turned out that the function that .lib expected to find is 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 to (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 understand why this incompatibility occurred, but in the end I gave up, recompiled the same visual studio project in VS2008 and used this SystemC.lib instead of the one from VS2003. Now everything worked perfectly.

So, the main question here is: what has changed from VS2003 to VS2008, what can cause some functions to change their calling conventions? And is there some kind of magic flag to let the linker in VS2008 use some other library, where the functions have the same calling convention as in the VS2003 compilation?

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

The main problem was discovered with a tip in:

Please note that these questions did not answer this problem:

+4
source share
2 answers

There is no standard for C ++ ABI. This means that the entire C ++ compiler can handle different ABIs from one to another, and which includes a different version from the same compiler. You may have the same problem with two different versions of Gcc. Such a modification may occur when they find a way to improve the binding step.

But ABI assumes much more than that. For example, the vtable path is stored and processed behind the hood by code generated by the compiler. If it changes, your objects and your code generated in 2008 will not be compatible with the library that expects to be done in 2003.

At this point, you could understand why C ++ libraries are either sent with source code or sent compiled in many different architectures and compilers.

Usually, when you write a library to avoid such problems, you develop it in C langage, not C ++. Since C comes with a standardized ABI, you can compile it with one compiler and then link this library to any C compiler that complies with this C ABI standard. For example, a character string implementation is standard and probably will never move (the infamous zero-terminated string). While the implementation of std :: string changes from one Gcc release to another (just look in the basic_string class from / usr / include / c ++ / xx / bits / basic_string files)

+3
source

As far as I know, these problems arise due to the CRT library, they change with the main releases, and you should not mix CRT types (multithreaded, debugging, release, static, dynamic, etc.).

Usually they can be minimized by dynamically linking to CRT, I have successfully used VS2003 libraries in VS2005, but this is annoying, it's better to just recompile it all. Sometimes you can get away using the / NODEFAULTLIB compiler flag to avoid linking to a specific CRT library that causes problems.

+2
source

More articles:


All Articles