如何*防止* Visual-C++ 中静态库符号的“弱”链接？答案

【问题标题】：How do I *prevent* "weak" linking of static library symbols in Visual-C++?如何*防止* Visual-C++ 中静态库符号的“弱”链接？
【发布时间】：2014-11-04 13:52:04
【问题描述】：

就我的实际测试而言，在将静态库 (.lib) 链接到 Visual-C++ 中的可执行文件时，如果任何可执行的 .obj 文件在静态库，静态库中的符号将被默默地忽略。

Confirm ( Feb 18 '10 at 17:46 Michael Burr):

MSVC 过去的行为是，如果在 .obj 文件中定义了符号和一个 .lib 它会在没有警告的情况下使用 .obj 文件上的那个。一世回想一下，它还可以处理符号所在的情况在多个库中定义，它将使用名为列表中的第一位。

我不能说我已经尝试过一段时间了，但如果他们这样做，我会感到惊讶改变了这种行为（特别是 .obj 定义的符号覆盖 .lib 文件中的符号）。

对 VS 2010 RC 的简短测试表明我描述的行为仍然存在。

（'Windows Static Library with Default Functions' seems also a confirmation 给我）

首先，我很想被证明是错误的，但至少对于常规的 C++ 函数来说，情况似乎是这样的。

其次，有什么办法可以防止这种情况发生吗？我有一个函数，当任何二进制链接到包含此函数的静态库时，我想确认静态库中的版本是实际使用的，而不是一些剩余的或其他的任何东西项目。（请注意：有问题的 Fn 是 test_suite* init_unit_test_suite(int argc, char* argv[]), (*) 所以我实际上无法更改它，因为它来自第三方库。）

(*): _{这是 Boost.Test 主函数，应该由我们的自定义静态库提供。如果任何开发人员创建了一个单元测试项目——它通过属性表自动链接到静态库——但也错误地定义了函数，则构建应该中断而不是使用开发人员提供的函数。}

【问题讨论】：

功能，不是错误。使用映射文件或链接器的 /VERBOSE 选项进行诊断。
@HansPassant - 我从未说过这是一个错误。它只是......好吧，这并不是一直以来的最佳选择。我不想诊断它，我想在它发生时出现构建错误。

标签： c++ visual-c++ linker static-libraries weak-linking

【解决方案1】：

我认为如果您链接独立的 obj 文件，而不是打包在静态库中，链接器的行为会有所不同。至少你应该得到一些关于符号重复的警告/错误。

When I needed something similar 不久前我在 MS 工具链中也找不到它，但有两个 MS 设备很接近并且可能很方便：__declspec(selectany) 和未记录的#pragma /alternatename。也许链接到 obj 文件并将符号声明为 selectany 可以解决问题？如果没有，也许在 exe-obj 文件中添加 #pragma comment(linker, "/alternatename:_YourSymbol=_DefaultExeSymbol") 即可。

【讨论】：

我实际上在发布 Q 之前阅读了您的博客文章，但认为它没有帮助。 selectany 和 alternatename 都用于与我想要的相反的情况，即当你通常不得到它时获得弱链接。直接链接到目标文件实际上可能有效（查看工具链如何正常工作），但由于这是一个第 3 方库，我目前不知道如何在不使其成为无法维护的混乱的情况下做到这一点。
不确定我是否理解。你不想在你的 exe 中强制弱链接吗？这正是导致 lib 定义的符号在重复的情况下接管的原因。 IIUC 你应该可以用 pragma alternatename 得到这个。
嗯，好的。那是另一个转折。我真正喜欢的是 not 在我的可执行文件中完全没有该符号并强制执行该符号。你看，这是应该由我们的自定义静态库提供的 Boost.Test 主函数。如果任何开发人员创建了单元测试项目（这些项目通过属性表自动链接到静态库）但也错误地定义了函数，则构建应该中断而不是使用开发人员提供的函数。
有点骇人听闻，但您仍然可以像上面一样使用#pragma /alternatename 并让_DefaultExeSymbol 破坏构建。