When using fstream in a library I get linker error

Question

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?

Answer 1

for anyone like me that this answer did not ring helpful, a second option is to go to: Project Properties->Configuration Properties->General->Project Defaults->.NET Target Framework Version and set it to v4.0

https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli has an obscure answer from Microsoft team that fixed my issue.

I also added this answer to another version of the same problem.

Answer 2

5+ years later... the problem (and maybe many others) is already solved (and forgotten :) )

You have 1 lib proj 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 proj that makes use of the previous one.
I've thought about what could the configuration that would yield this behavior be (the lib proj building fine and the app proj having these unresolved externals) and the only configuration that stands up is: the lib proj is not correct. Let me detail:

• 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:
  1. The lib proj is fine, and the error is in the app proj.
  2. The lib proj is not fine (and the app proj 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 (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, ...).
• The fact that there were no duplicate symbols at link time (app proj) rules out the 1st option.

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 proj.

¹ 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]: 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):

• have significantly larger size.
• run slower.

The code addition is typically achieved by differences between build steps (simplified version):

• 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.

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 proj, so you have a CRT mismatch (as the 3^rd comment states). To fix this, either:

• change the _DEBUG/NDEBUG macro definition from: Project Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions
• change CRT type from: Project Properties -> C/C++ -> Code Generation -> Runtime Library

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.