簡單地通過添加一個#include

C++ VS2008鏈接器錯誤（已定義）我有一個應用程序用VS2008 C++編寫，長時間以來一直在正常工作。它由幾個靜態lib項目組成，全部鏈接成一個.exe簡單地通過添加一個#include

在一些維護過程中，我在其中一個靜態庫項目中添加了一個額外的#include到其中一個.cpp文件，導致exe（一個單獨的項目）拒絕鏈接。如果我刪除了有問題的#include（並嘗試重新考慮維護更改），但問題已得到解決，但顯然有些事情並不完全正確，我需要深入其中。

鏈接錯誤是：

Error 3 error LNK2005: "void * __cdecl operator new(unsigned int)" ([email protected]@Z) already defined in LIBCMTD.lib(new.obj) nafxcwd.lib 
Error 4 error LNK2005: "void __cdecl operator delete(void *)" ([email protected]@Z) already defined in LIBCMTD.lib(dbgdel.obj) nafxcwd.lib 
Error 5 error LNK2005: "void __cdecl operator delete[](void *)" ([email protected]@Z) already defined in LIBCMTD.lib(delete2.obj) nafxcwd.lib 
Error 6 fatal error LNK1169: one or more multiply defined symbols found Tmtka.exe 1

這些通常指向由各個的.lib（S）和所述可執行使用CRT庫的版本（靜態VS動態）不一致。但是，所有的.lib和可執行文件都是使用「/ MT」和「在靜態庫中使用MFC」始終構建的。

另一個難題是，當所有.lib（s）和可執行文件始終設置爲「/ MD」和「在共享DLL中使用MFC」，問題就會消失。但是，我們希望繼續以靜態鏈接（自包含）的形式繼續發佈應用程序，因此我們想要了解如何在繼續使用「/ MT」和「在靜態庫中使用MFC」的情況下解決此問題」。

沒有使用明確的第三方庫，但VS2008很可能鏈接到一些可能動態鏈接到CRT或MFC的引擎，從而導致這個問題。但是，那麼爲什麼只有在經過多年的成功操作之後，這個問題纔會體現出來，這是因爲簡單介紹了這個不幸的#include指令？

也許是圖書館問題的排序？

「附加依賴」中的顯式庫的排序方式使得那些依賴於其他庫的庫首先出現，即使MSCV鏈接器不應該遭受這種試圖阻止與gcc所認爲的一樣嚴重的問題。但是我有一種感覺，如果這是一個排序問題，它可能會與引擎罩依賴關係的排序有關。

我該如何着手解決這個問題？我應該使用哪些工具？我想帶的Depends.exe，但它似乎並不想打開.lib文件（我想確保我理解他們的依賴）

請幫助...

來源

2014-01-29 OldSchool

嘗試使用'/ VERBOSE：LIB'鏈接器開關構建 - 它會告訴您鏈接器引入哪些庫。比較包含和不包含該頭時的輸出。 –

那麼，請在#included文件中查找運算符new和delete的替換。您不希望它們在Debug版本中使用#ifndef DEBUG包裝它們。 –

@HansPassant。感謝Hans。我應該說，#include用於其他編譯單元已經包含在同一個庫中的文件。它不重新定義任何內存分配操作符。 – OldSchool

我有同樣的問題。當我使用MFC靜態鏈接編譯我的項目時，出現了這個問題，並且在我的項目中添加了另一個使用MFC靜態鏈接的庫。將預編譯頭文件的C++項目選項更改爲/ Yu（，使用預編譯頭文件）的功能非常神奇。

來源

2015-04-08 09:57:52 McKool

簡單地通過添加一個#include

回答

相關問題