c-在库中使用fstream时,在可执行文件中出现链接器错误
作者：互联网
当我添加
#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
有什么想法吗？
解决方法:
5年后…问题(也许还有许多其他问题)已经解决了(并且被遗忘了:))
您有1个包含以上代码的lib proj：我假设它在.c(xx)文件中,而不是在.h文件中(两个项目中都包含),并且有一个使用前一个项目的app proj.我已经考虑过产生这种行为的配置是什么(lib proj构建良好,而app proj具有这些未解决的外部条件),唯一能站出来的配置是：lib proj不正确.让我详细说明一下：
>一个缺少的符号是CrtDbgReport,它告诉我该库是在Debug模式下构建的.
> lib正在运行的事实告诉我：
> lib proj正常,并且错误在app proj中.
> lib proj不合适(应用程序proj可能会也可能不会),但是它是一个静态库-在这种情况下,.obj文件只是简单地“合并”到了生成的.lib文件中-它没有链接因此,链接器此时不搜索未解析的外部对象,并且仅在将库链接到可执行文件(.exe或.dll)时才搜索.我在错误日志中看到libcpmtd.lib1的事实对此提供了支持：使用静态运行时库(CRT)版本(尤其是在包含库的项目中)仅在构建静态应用程序(通常设计为在以下环境中运行)时才有意义剥离的环境-例如,在“ Windows简约核心”分发中,该环境仅需要诸如ntdll.dll,kernel32.dll等的核心库.
>链接时(应用程序项目)没有重复的符号这一事实排除了第一个选项.
这样更好,我们可以简化再现行为所需的环境.您可以切换项目属性->配置属性->一般->配置类型,然后从静态库(.lib)更改为动态库(.dll).现在,在构建lib proj时,它将最终链接并吐出错误.
1检查[SO]: Errors when linking to protobuf 3 on MSVC 2013以获取有关CRT链接类型的详细信息(也请检查链接).另请检查[SO]: LNK2005 Error in CLR Windows Form,以获取有关构建C和C代码时发生的情况的更多详细信息.
关于[MSDN]: Debug vs Release构建的一些说明：在Debug模式下进行构建时,会将一些检测代码静默添加到您的代码中以方便调试.这就是为什么Debug构建工件(相对于其Release版本)：
>具有更大的尺寸.
>慢一点.
通常通过构建步骤之间的差异(简化版本)来实现代码添加：
>预处理：定义了_DEBUG宏(与定义NDEBUG的Release版本相反).您可以浏览标准包含文件,并且在这些宏上会看到许多预处理器指令(主要是#ifdefs).此阶段对编译阶段有直接影响.
>链接：选择了正确的库(实际上包含该检测代码).
最重要的是,编译(和间接预处理)和链接阶段必须同步.对于lib proj并非如此,因此您的CRT不匹配(如第3条评论所述).要解决此问题,请执行以下任一操作：
>从以下项目更改_DEBUG / NDEBUG宏定义：项目属性-> C/C++->预处理器->预处理程序定义
>从以下项目更改CRT类型：项目属性-> C/C++->代码生成->运行时库
我列出了它们两者,因为我不知道哪一个是不正确的(因为您希望配置设置与配置名称(调试/发布)相匹配),但是我感觉是后者.
另外,请确保在应该一起工作的项目之间具有一致的设置.
标签：c,visual-c,lnk2019,lnk2001 来源： https://codeday.me/bug/20191013/1908318.html