当我添加
#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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。