C++ 调试链接错误的最佳实践
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/34955/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best practices for debugging linking errors
提问by tsellon
When building projects in C++, I've found debugging linking errors to be tricky, especially when picking up other people's code. What strategies do people use for debugging and fixing linking errors?
在用 C++ 构建项目时，我发现调试链接错误很棘手，尤其是在获取其他人的代码时。人们使用什么策略来调试和修复链接错误？
采纳答案by Joe Schneider
Not sure what your level of expertise is, but here are the basics.
不确定您的专业水平是什么，但这里是基础知识。
Below is a linker error from VS 2005 - yes, it's a giant mess if you're not familiar with it.
下面是来自 VS 2005 的链接器错误 - 是的，如果您不熟悉它，那将是一个巨大的混乱。
ByteComparator.obj : error LNK2019: unresolved external symbol "int __cdecl does_not_exist(void)" (?does_not_exist@@YAHXZ) referenced in function "void __cdecl TextScan(struct FileTextStats &,char const *,char const *,bool,bool,__int64)" (?TextScan@@YAXAAUFileTextStats@@PBD1_N2_J@Z)
There are a couple of points to focus on:
有几点需要重点关注：
- "ByteComparator.obj" - Look for a ByteComparator.cpp file, this is the source of the linker problem
- "int __cdecl does_not_exist(void)" - This is the symbol it couldn't find, in this case a function named does_not_exist()
- "ByteComparator.obj" - 寻找一个 ByteComparator.cpp 文件，这是链接器问题的根源
- "int __cdecl does_not_exist(void)" - 这是它找不到的符号，在这种情况下是一个名为 dos_not_exist() 的函数
At this point, in many cases the fastest way to resolution is to search the code base for this function and find where the implementation is. Once you know where the function is implemented you just have to make sure the two places get linked together.
此时，在许多情况下，最快的解决方法是搜索此函数的代码库并找到实现的位置。一旦你知道函数在哪里实现，你只需要确保这两个地方链接在一起。
If you're using VS2005, you would use the "Project Dependencies..." right-click menu. If you're using gcc, you would look in your makefiles for the executable generation step (gcc called with a bunch of .o files) and add the missing .o file.
如果您使用的是 VS2005，您将使用“项目依赖项...”右键菜单。如果您使用 gcc，您将在您的 makefile 中查找可执行文件生成步骤（gcc 使用一堆 .o 文件调用）并添加丢失的 .o 文件。
In a second scenario, you may be missing an "external" dependency, which you don't have code for. The Win32 libraries are often times implemented in static libraries that you have to link to. In this case, go to MSDNor "Microsoft Google"and search for the API. At the bottom of the API description the library name is given. Add this to your project properties "Configuration Properties->Linker->Input->Additional Dependencies" list. For example, the function timeGetTime()'s page on MSDNtells you to use Winmm.lib at the bottom of the page.
在第二种情况下，您可能缺少“外部”依赖项，您没有代码。Win32 库通常在您必须链接到的静态库中实现。在这种情况下，请转到MSDN或“Microsoft Google”并搜索 API。在 API 描述的底部给出了库名称。将此添加到您的项目属性“配置属性->链接器->输入->附加依赖项”列表中。例如，MSDN 上的函数 timeGetTime()页面告诉您使用页面底部的 Winmm.lib。
回答by Nathan Fellman
One of the common linking errors I've run into is when a function is used differently from how it's defined. If you see such an error you should make sure that every function you use is properly declared in some .h file.
You should also make sure that all the relevant source files are compiled into the same lib file. An error I've run into is when I have two sets of files compiled into two separate libraries, and I cross-call between libraries.
我遇到的常见链接错误之一是函数的使用方式与其定义方式不同。如果您看到这样的错误，您应该确保您使用的每个函数都在某个 .h 文件中正确声明。
您还应该确保所有相关的源文件都编译到同一个 lib 文件中。我遇到的一个错误是当我将两组文件编译到两个单独的库中，并且我在库之间交叉调用时。
Is there a failure you have in mind?
你有什么失败的想法吗？
回答by Rob Walker
The C-runtime libraries are often the biggest culprit. Making sure all your projects have the same settings wrt single vs multi-threading and static vs dll.
C 运行时库通常是最大的罪魁祸首。确保您的所有项目都具有相同的设置 wrt 单线程 vs 多线程以及静态 vs dll。
The MSDN documentation is good for pointing out which lib a particular Win32 API call requires if it comes up as missing.
MSDN 文档非常适合指出特定 Win32 API 调用在丢失时需要哪个库。
Other than that it usually comes down to turning on the verbose flag and wading through the output looking for clues.
除此之外，它通常归结为打开详细标志并在输出中寻找线索。
