在库中使用 fstream 时，我在可执行文件中收到链接器错误

时间：2023-07-02

本文介绍了在库中使用 fstream 时，我在可执行文件中收到链接器错误的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着跟版网的小编来一起学习吧！

问题描述

当我添加

#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@@QAEAAPA_WI@Z) C:zipprojnotworkingCPP7zipUITestingZipperConsole.lib(ZipLib.obj)  TestingZipper
Error   3   error LNK2001: unresolved external symbol __CrtDbgReportW C:zipprojnotworkingCPP7zipUITestingZipperlibcpmtd.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@AAEXXZ) C:zipprojnotworkingCPP7zipUITestingZipperConsole.lib(ZipLib.obj)  TestingZipper
Error   5   error LNK2001: unresolved external symbol __free_dbg    C:zipprojnotworkingCPP7zipUITestingZipperlibcpmtd.lib(xdebug.obj) TestingZipper
Error   6   error LNK2001: unresolved external symbol __free_dbg    C:zipprojnotworkingCPP7zipUITestingZipperlibcpmtd.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@PADH@Z) C:zipprojnotworkingCPP7zipUITestingZipperlibcpmtd.lib(xdebug.obj) TestingZipper
Error   8   error LNK2001: unresolved external symbol __malloc_dbg  C:zipprojnotworkingCPP7zipUITestingZipperlibcpmtd.lib(locale0.obj)    TestingZipper
Error   9   error LNK2019: unresolved external symbol __calloc_dbg referenced in function __Getctype    C:zipprojnotworkingCPP7zipUITestingZipperlibcpmtd.lib(_tolower.obj)   TestingZipper Error 10  error LNK1120: 4 unresolved externals   C:zipprojnotworkingCPP7zipUIConsoleDebugTestingZipper.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 项目具有这些未解析的外部/em>) 而唯一站得住脚的配置是: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，它告诉我该库是在调试模式下构建的.
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:

lib 项目没问题，错误在app 项目
lib 项目不好(app 项目可能好也可能不好)但它是一个静态库 - 并且在在这种情况下，.obj 文件只是在生成的 .lib 文件中合并"在一起 - 它未链接，因此链接器不会搜索对于此时未解析的外部文件，它只会搜索该库何时链接到可执行文件(.exe 或 .dll)中.这是因为我在错误日志中看到了 libcpmtd.lib⁽¹⁾:使用静态运行时库 ((U)CRT) 版本(尤其是在包含库的项目中)仅在构建静态应用(通常设计为在中运行时才有意义)em>剥离环境 - 例如在Windows 简约核心"发行版上，它只需要核心库，例如:ntdll.dll、kernel32.dll, ...).

The lib project is fine, and the error is in the app project

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 项目)排除了第一个^选项.

这样更好，我们可以简化重现行为所需的环境.您可以切换项目属性 -> 配置属性 -> 常规 -> 配置类型并从 静态库 (.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]:在 MSVC 2013 上链接到 protobuf 3 时出错，了解有关 CRT 链接类型的详细信息(也请检查链接).还要检查 [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 vs Release 构建:在调试模式下构建时，一些检测代码会悄悄地添加到您的代码中以方便调试.这就是为什么调试构建工件(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 不匹配(如第三条评论所述).要解决此问题，要么:

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:

更改 _DEBUG/NDEBUG 宏定义:项目属性 -> C/C++-> 预处理器 -> 预处理器定义
将 UCRT 类型从:项目属性 -> C/C++ -> 代码生成 -> 运行时库

我列出了它们，因为我不知道哪个不正确(因为您希望配置设置与配置名称匹配(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 时，我在可执行文件中收到链接器错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！

上一篇：将 Unicode 转换为多字节 下一篇：使用 Win32 API 列出存储在纯资源库 (DLL) 中的消息 ID 和符号名称

相关文章

调用函数时 C++ 访问冲突读取位置 0xcdcdcdcd 错误

SFML 在多线程中失败

C++ 编译器如何合并相同的字符串文字

timegm 跨平台

如何在内部函数中使用 if 条件

IsBadReadPtr 的最有效替代品?

强制转换的结果是右值吗?

为什么 Visual C++ 在 C 中对从 const void ** 到 void * 的隐式转换发出警告，但在 C

如何从根目录包含 stdafx.h?

(已知)VC12 中的编译器错误?