在庫使用fstream的，我得到的可執行文件鏈接錯誤

Question

當我添加

#include <fstream> 

，並嘗試使用

std::ifstream (i.e. std::ifstream ifile(pDest)) 

在我的圖書館我得到編譯項目時，下面的鏈接錯誤whih使用庫：

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 

任何想法爲什麼？

Answer 1

5+年後...問題（也許很多人）已經解決了（和被遺忘的:)）

您有一個包含上面的代碼1個LIB凸出：我想這是一個。 c（xx）文件，而不是.h文件（包含在兩個項目中）以及使用前一個文件的應用程序。
我想過會產生這種行爲的配置是什麼（lib proj構建良好，並且應用程序具有這些未解決的外部問題），唯一能夠站起來的配置是：lib proj不正確。讓我詳細：

• 一人失蹤符號是CrtDbgReport，告訴我的lib建在調試模式。
• 的LIB正在建設OK的事實，告訴我，要麼：
  1. 的LIB凸出是好的，錯誤是在應用程序中凸出。
  2. 的LIB凸出不精（和應用程序凸出可能會或可能不會被罰款），但它是一個靜態庫 - 在這種情況下，.OBJ文件只是簡單地在產生「合併」在一起。 LIB文件 - 它不掛因此鏈接不搜索在這一點上無法解析的外部，當這個庫將在一個可執行文件（.exe文件或 .dll文件）鏈接只會搜索。這是因爲我在錯誤日誌中看到libcpmtd.lib ：使用靜態運行時庫（CRT）版本（特別是在包含庫的項目中）只有在構建靜態應用程序（通常被設計成在剝離出來環境中運行 - 例如在的「Windows核心簡約」分佈在那裏它可能只需要像核心庫：ntdll.dll中，KERNEL32.DLL ...） 。
• 鏈接時沒有重複符號（app proj）的事實排除了第一個選項。

這樣比較好，我們可以簡化再現行爲所需的環境。您可以切換項目屬性 - >配置屬性 - >常規 - >配置類型，並從更改靜態庫（。lib）到動態庫（.dll）。現在，最終它會鏈接並且在構建lib proj時將錯誤地吐出錯誤。

檢查[SO]: Errors when linking to protobuf 3 on MSVC 2013有關CRT鏈接類型的詳細信息（也請查看鏈接）。另請參閱[SO]: LNK2005 Error in CLR Windows Form瞭解有關構建C和C++代碼時發生的情況的更多詳細信息。

關於[MSDN]: Debug vs Release構建的幾句話：在調試模式下編譯時，會在代碼中靜默添加一些儀表代碼以便於調試。這就是爲什麼調試構建工件（VS其發行同行）：

• 有顯著更大的尺寸。
• 運行速度較慢。
  • 預處理：所述_DEBUG宏被定義（與釋放其中NDEBUG定義）

  的代碼除了通常由（簡化版本）的構建步驟之間的差異來實現。你可以瀏覽標準的包含文件，你會在這些宏中看到大量的預處理指令（主要是#ifdef）。這一階段對編譯階段有直接影響。

• 鏈接：選擇正確的庫（實際上包含該檢測代碼）。

最重要的事情是，編譯（並間接預處理）和鏈路階段必須同步。這不是你的lib proj的情況，所以你有一個CRT不匹配（如評論狀態3）。爲了解決這個問題，要麼：

• 變化從_DEBUG/NDEBUG宏定義：項目屬性 - > C/C++ - >預處理器 - >預處理定義
• 變化CRT類型從：項目屬性 - > C/C++ - >代碼生成 - >運行時庫

我列出了他們兩個，因爲我不知道哪一個是不正確的（正如您希望的配置設置搜索gs以匹配配置名稱（調試/版本）），但我有一種感覺，它是後者。

此外，請確保跨應該一起工作的項目具有一致的設置。

Answer 2

對於像我這樣的人來說，這個答案沒有幫助，第二個選項是去： Project Properties-> Configuration Properties-> General-> Project Defaults->。NET目標框架版本並將其設置爲V4.0

https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli有來自微軟的團隊，固定我的問題一個不起眼的答案。

我也將此答案添加到同一問題的另一個版本。