在库中使用fstream时，在可执行文件中出现链接器错误 [英] When using fstream in a library I get linker errors in the executable

问题描述

当我添加

#include <fstream>

并尝试使用

std::ifstream (i.e. std::ifstream ifile(pDest))

在我的库中，编译使用该库的项目时出现以下链接器错误:

in my library I get the following linker errors when compiling a project whih uses the library:

Error   2   error LNK2019: unresolved external symbol __CrtDbgReportW referenced in function "public: wchar_t * & __thiscall std::vector<wchar_t *,class std::allocator<wchar_t *> >::operator[](unsigned int)" (??A?$vector@PA_WV?$allocator@PA_W@std@@@std@@QAEAAPA_WI@Z) C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\Console.lib(ZipLib.obj)  TestingZipper
Error   3   error LNK2001: unresolved external symbol __CrtDbgReportW C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(stdthrow.obj) TestingZipper
Error   4   error LNK2019: unresolved external symbol __free_dbg referenced in function "private: void __thiscall std::_Yarn<char>::_Tidy(void)" (?_Tidy@?$_Yarn@D@std@@AAEXXZ) C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\Console.lib(ZipLib.obj)  TestingZipper
Error   5   error LNK2001: unresolved external symbol __free_dbg    C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(xdebug.obj) TestingZipper
Error   6   error LNK2001: unresolved external symbol __free_dbg    C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(locale0.obj)    TestingZipper
Error   7   error LNK2019: unresolved external symbol __malloc_dbg referenced in function "void * __cdecl operator new(unsigned int,struct std::_DebugHeapTag_t const &,char *,int)" (??2@YAPAXIABU_DebugHeapTag_t@std@@PADH@Z) C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(xdebug.obj) TestingZipper
Error   8   error LNK2001: unresolved external symbol __malloc_dbg  C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(locale0.obj)    TestingZipper
Error   9   error LNK2019: unresolved external symbol __calloc_dbg referenced in function __Getctype    C:\zipprojnotworking\CPP\7zip\UI\TestingZipper\libcpmtd.lib(_tolower.obj)   TestingZipper Error 10  error LNK1120: 4 unresolved externals   C:\zipprojnotworking\CPP\7zip\UI\Console\Debug\TestingZipper.exe    TestingZipper

有什么想法吗?

推荐答案

5年后……这个问题(也许还有许多其他问题)已经解决了(并且被遗忘了:))

5+ years later... the problem (and maybe many others) is already solved (and forgotten :) )

您有1个 lib 项目，其中包含上面的代码:我假设它在 .c(xx)文件中，而不在 .h 中.em>文件(包含在两个项目中)和一个使用前一个项目的 app 项目.
我已经考虑过产生这种行为的配置是什么( lib 项目构建良好，而 app 项目具有这些未解决的外部因素)，唯一站立的配置是: lib 项目不正确.让我详细说明:

You have 1 lib project that contains the code above: I assume it's in a .c(xx) file and not in a .h file (included in both projects), and an app project that makes use of the previous one.
I've thought about what could the configuration that would yield this behavior be (the lib project building fine and the app project having these unresolved externals) and the only configuration that stands up is: the lib project is not correct. Let me detail:

• 一个丢失的符号是 CrtDbgReport ，它告诉我该库是在 Debug 模式下构建的.
• lib 正在构建 OK 的事实告诉我，要么:

• One missing symbol is CrtDbgReport, that tells me that the lib is built in Debug mode.
• The fact that the lib is building OK, tells me that either:

1. lib 项目很好，并且错误在 app 项目
中
2. lib 项目不是很好(而 app 项目可能是也可能不是)，但是它是一个 static 库-在在这种情况下， .obj 文件只是简单地合并"到了生成的 .lib 文件中-它是未链接，因此链接器不会搜索此时尚未解析的外部对象，并且仅在将此库链接到可执行文件( .exe 或 .dll )中时才会搜索.我在错误日志中看到 libcpmtd.lib ⁽¹⁾ 的事实对此提供了支持:静态运行时库((U)CRT)版本(尤其是在包含库的项目中)仅在构建静态 app (通常设计为在扩展环境-例如在" Windows简约内核"发行版中，该发行版仅需要诸如 ntdll.dll ， kernel32之类的核心库.dll ，...).

1. The lib project is fine, and the error is in the app project
2. The lib project is not fine (and the app project may or may not be fine) but it's a static library - and in this case the .obj files are simply "merged" together in the resulting .lib file - it is not linked so the linker does not search for unresolved externals at this point and it will only search when this library will be linked in an executable (.exe or .dll). This is backed out by the fact that I saw libcpmtd.lib⁽¹⁾ in the error log: using the static runtime library ((U)CRT) version (especially in a project that contains libraries) only makes sense when building a static app (usually designed to run in a stripped out environment - e.g. on a "Windows minimalistic core" distribution where it could only need core libraries like: ntdll.dll, kernel32.dll, ...).

在链接时( app 项目)没有重复的符号这一事实排除了1 ^st选项.

The fact that there were no duplicate symbols at link time (app project) rules out the 1^{st option.}

这样可以更好地简化复制行为所需的环境.您可以切换项目属性->配置属性->常规->配置类型，然后从静态库(.lib)更改为动态库(.dll).现在，它最终将链接，并且在构建 lib 项目时将无法吐出错误.

This is better that we can simplify the environment required for reproducing the behavior. You can switch Project Properties -> Configuration Properties -> General -> Configuration Type and change from Static Library (.lib) to Dynamic Library (.dll). Now, at the end it will link and will fail spitting the errors when building the lib project.

¹ 检查 [SO]:CLR Windows窗体中的LNK2005错误有关构建 C 和 C ++ 代码时发生的情况的详细信息.

¹ Check [SO]: Errors when linking to protobuf 3 on MSVC 2013 for details about the CRT linking types (check the links as well). Also check [SO]: LNK2005 Error in CLR Windows Form for more details about what happens when building C and C++ code.

关于> [MSDN.Blogs]:调试与发布构建:在 Debug 模式下进行构建时，一些检测代码会静默添加到您的代码中以方便调试.这就是为什么 Debug 构建构件( vs 与它们的 Release 对应物)的原因:

A few words about [MSDN.Blogs]: Debug vs Release builds: when building in Debug mode, some instrumentation code is silently added in your code to facilitate debugging. That's why Debug build artifacts (vs their Release counterparts):

• 具有更大的尺寸
• 慢一点

代码添加通常是通过构建步骤(简化版本)之间的差异来实现的:

The code addition is typically achieved by differences between build steps (simplified version):

• 预处理:已定义 _DEBUG 宏(与 Release 相对，其中 NDEBUG 已定义).您可以浏览标准包含文件，并且在这些宏上会看到很多预处理器指令(主要是 #ifdef ).此阶段对编译阶段有直接影响
• 链接:选择了正确的库(实际上包含该检测代码)

• Preprocess: the _DEBUG macro is defined (as opposed to Release where NDEBUG is defined). You can browse standard include files and you'll see lots of preprocessor directives (#ifdefs mostly) on these macros. This phase has a direct impact on compile phase
• Link: the right libraries (that actually contain that instrumentation code) are chosen

最重要的是，编译(和间接地，预处理)和链接阶段必须保持同步.您的 lib 项目不是这种情况，因此您有 UCRT 不匹配的情况(如第3 条注释所述).要解决此问题，请选择:

The most important thing is that the compile (and indirectly, preprocess) and link phases must be in sync. This is not the case for your lib project, so you have an UCRT mismatch (as the 3rd comment states). To fix this, either:

• 从 Project Properties-> C/C ++更改 _DEBUG / NDEBUG 宏定义->预处理程序->预处理程序定义
• 从以下项目中更改 UCRT 类型:项目属性-> C/C ++->代码生成->运行时库

• Change the _DEBUG / NDEBUG macro definition from: Project Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions
• Change UCRT type from: Project Properties -> C/C++ -> Code Generation -> Runtime Library

我列出了它们两者，因为我不知道哪一个是不正确的(因为您希望配置设置与配置名称匹配( Debug / Release )))，但我感觉是后者.

I listed them both, since I don't know which one is incorrect (as you would want the configuration settings to match the configuration name (Debug / Release)), but I have a feeling that it's the latter.

此外，请确保在应该一起工作的项目之间具有一致的设置.

Also, make sure to have consistent settings across projects that are supposed to work together.

这篇关于在库中使用fstream时，在可执行文件中出现链接器错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！