When I add
#include <fstream>
and try to use
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@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
Any ideas why?
5+ years later... the problem (and maybe many others) is already solved (and forgotten :) )
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:
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.
1 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.
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):
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:
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.