visual-studio-2008 - 为什么在 VS2003 中编译的 .lib 无法与使用 VS2008 编译的代码链接？

Question

在尝试将使用 Visual Studio Express 2008 编译的一组代码与使用 Visual Studio 2003 编译的 .lib 链接时，我们刚刚获得了一个有趣的体验。全部使用 C++。准确的说是SystemC 2.2.0内核在VS2003编译成.lib，SystemC模型在VS2008编译。

链接时，一直报错，链接过程中找不到SystemC.lib文件(即VS2003编译)中的一些符号。我们得到的错误是这样的(在一些变体中):

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)

从各种线索挖掘，结果 .lib 期望找到的函数是这样的:

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

虽然 VS2008 试图链接的库文件 (libcpmt.lib) 使用了不同的调用约定:

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

我试图弄清楚为什么会发生这种不兼容，但最后我放弃了，在 VS2008 中重新编译了完全相同的 Visual Studio 项目，并使用了 SystemC.lib 而不是 VS2003 中的那个。现在，一切顺利。

所以这里的基本问题是:从 VS2003 到 VS2008 有什么变化会导致某些函数改变它们的调用约定？是否有一些神奇的标志可以给 VS2008 中的链接器使用其他一些库，其中函数具有与 VS2003 编译中相同的调用约定？

更新，到目前为止的答案摘要:Microsoft 很可能将 C++(不是 C，只是 C++)ABI 从 Visual Studio 的一个主要版本更改为下一个版本。库中还可能存在其他导致不兼容的更改。最好的建议是为每个版本的 VS 重新编译 .lib。本质上，只需将它以源代码的形式发送给用户，并让他们使用他们碰巧安装的任何版本的 VS 在本地编译它。

通过使用以下建议发现了基本问题:

LNK2001 error when compiling apps referencing STLport-5.1.4 with VC++ 2008

请注意，这些问题没有回答这个问题:

can you create a lib or dll in VS 2005 and link with VS 2008

Answer 1

C++ ABI 没有标准。这意味着所有 C++ 编译器都可以处理不同的 ABI，包括来自同一编译器的不同版本。您可能会遇到来自 Gcc 的 2 个不同主要版本的相同问题。
当他们找到改进链接步骤的方法时，可能会发生这种修改。

但 ABI 涉及的远不止这些。例如，通过编译器生成的代码存储和处理 vtable 的方式。如果它发生变化，您的对象和您在 2008 年生成的代码将与库不兼容，预计它会以 2003 年的方式完成。

在这一点上，您可以理解为什么 c++ 库要么随其源代码一起提供，要么在 上编译后提供。许多 不同的架构和编译器。

通常在编写库时，为了避免此类问题，您使用 C 语言而不是 C++ 开发它。由于 C 带有标准化的 ABI，您可以使用一个编译器对其进行编译，然后将该库与任何符合该 C ABI 标准的 C 编译器链接。
例如，字符串的实现方式是标准的，可能永远不会移动(臭名昭著的空终止字符串)。
虽然 std::string 实现从一个 Gcc 主要版本更改为另一个(只需查看/usr/include/c++/x.x/bits/basic_string 文件中的 basic_string 类)