当我加上
#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知道为什么吗
2条答案
按热度按时间iezvtpos1#
5年多以后……这个问题（也许还有其他许多问题）已经解决了（并且被遗忘了：））
你有1 lib 项目包含上面的代码：我假设它在一个 .c（xx） 文件中，而不是在一个 .h 文件中（包括在两个项目中），并且一个 app 项目使用了前一个。
我已经考虑过会产生这种行为的配置是什么（lib 项目构建良好，而 app 项目具有这些 * 未解决的外部 *），唯一的配置是：lib项目不正确。让我详细说明一下：
1.事实上，lib 正在构建 OK，这告诉我：
1.lib 项目没问题，错误在 app 项目中
1.lib 项目并不好（app 项目可能好，也可能不好），但它是一个静态库-在本例中，.obj 文件只是简单地“合并”在结果 .lib 文件中
1.它是未链接，因此链接器此时不会搜索未解析的外部对象，并且仅在此库将链接到可执行文件（.exe 或 .dll）时才会搜索。我在错误日志中看到了 libcpmtd.lib***（1）*，这一事实证明了这一点：使用静态运行时库（（U）CRT）**版本（特别是在包含库的项目中）只有在构建静态 * 应用程序 （通常设计为在 * 剥离 * 环境中运行-例如在“Windows minimalistic core”发行版上，它可能只需要核心库，如：ntdll.dll，kernel32.dll，...）。
1.在链接时没有重复的符号（app project）排除了第一个选项。
这是更好的，我们可以简化再现行为所需的环境。您可以切换 * 项目属性->配置属性->常规->配置类型 ，并将 * 静态库（.lib） 更改为 * 动态库（.dll）。现在，在最后，它将链接并在构建 lib 项目时失败。
***1***查看[SO]: Errors when linking to protobuf 3 on MS Visual C (@CristiFati's answer)以了解有关CRT链接类型的详细信息（同时检查链接）。另外，请查看[SO]: LNK2005 Error in CLR Windows Form (@CristiFati's answer)，了解有关构建 C 和 C++ 代码时发生的情况的更多详细信息。
关于[MS.Learn]: Debug vs Release构建的几句话：当在 Debug 模式下生成时，一些检测代码会静默地添加到代码中以便于调试。这就是为什么 Debug 构建工件（vs 它们的 Release 对应物）：
代码添加通常通过构建步骤之间的差异来实现（简化版本）：
最重要的是编译（以及间接的预处理）和链接阶段必须同步。对于 lib 项目，情况并非如此，因此您有一个 UCRT 不匹配（如第3条注解所述）。要解决此问题，请使用或：
我列出了这两个，因为我不知道哪一个是不正确的（因为你希望配置设置匹配配置名称（Debug / Release）），但我有一种感觉，它是后者。
此外，确保在应该一起工作的项目之间具有一致的设置。
vql8enpb2#
对于像我这样的人，这个答案没有帮助，第二个选择是去：项目属性->配置属性->常规->项目默认->.NET目标框架版本，设置为v4.0
https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli有一个模糊的答案，从微软团队，解决了我的问题。
我还将这个答案添加到同一问题的另一个版本中。