c++ - 在库中使用fstream时，在可执行文件中出现链接器错误

Question

当我添加

#include <fstream>

并尝试使用

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

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

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

有什么想法吗？

Answer 1

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

您有1个lib项目，其中包含上面的代码:我假设它在.c(xx)文件中，而不在.h文件中(两个项目中都包含)，并且还有一个使用前一个项目的应用程序项目。我考虑过产生这种行为的配置是什么(lib项目构建良好，而应用程序项目具有这些未解决的外部问题)，唯一可以站出来的配置是:lib项目不正确。让我详细说明一下:

缺少的一个符号是 CrtDbgReport ，它告诉我该库是在 Debug模式下构建的。

lib正在建立的事实告诉我:

lib项目很好，并且错误在应用程序项目

中

lib项目不合适(应用程序项目可能也可能不行)，但是它是静态库-在这种情况下，.obj文件只是简单地“合并”到了生成的.lib文件中- 未链接，因此链接器此时不搜索未解析的外部文件，并且仅在将此库链接到可执行文件(.exe或.dll)时才搜索。我在错误日志中看到libcpmtd.lib (1)可以解决此问题:使用静态运行时库((U)CRT)版本(尤其是在包含库的项目中)仅在以下情况下才有意义构建一个静态应用程序(通常设计为在剥离的环境中运行-例如，在“Windows简约核心”发行版中，该发行版仅需要诸如ntdll.dll，kernel32.dll等核心库)。

链接时(应用程序项目)没有重复的符号这一事实排除了第一个选项。

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

1 检查 [SO]: Errors when linking to protobuf 3 on MSVC 2013以获取有关CRT链接类型的详细信息(也请检查链接)。另请检查 [SO]: LNK2005 Error in CLR Windows Form以获取有关构建C和C++代码时发生的情况的更多详细信息。

关于 [MSDN.Blogs]: Debug vs Release构建的几句话:在Debug模式下进行构建时，会将一些检测代码静默添加到您的代码中以方便调试。这就是为什么Debug构建 Artifact (与Release版本相对)的原因:

具有明显更大的大小

运行较慢的

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

预处理:定义了 _DEBUG 宏(与Release相对，其中定义了 NDEBUG )。您可以浏览标准包含文件，并且在这些宏上会看到很多预处理器指令( #ifdef )。此阶段对编译阶段

有直接影响

链接:选择正确的库(实际上包含该检测代码)

最重要的是，编译(和间接预处理)和链接阶段 必须同步。对于lib项目，情况并非如此，因此您遇到了UCRT不匹配的问题(如第3条评论所述)。要解决此问题，请 或:

从以下项更改 _DEBUG / NDEBUG 宏定义:项目属性-> C / C++->预处理程序->预处理程序定义

从以下项更改UCRT类型:项目属性-> C / C++->代码生成->运行时库

我列出了它们两者，因为我不知道哪个是不正确的(因为您希望配置设置与配置名称(调试/发行版)相匹配)，但是我感觉是后者。

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