2011-01-11 88 views
1
MFC Toolbox Library.lib(SimpleFileIO.obj) : error LNK2005: _wcsnlen already defined in libcmtd.lib(wcslen_s.obj) 
fatal error LNK1169: one or more multiply defined symbols found 

這讓我發瘋。通常情況下,如果作爲其解決方案一部分的各種項目不同意使用哪種CRT(單線程,多線程,發行版或調試版),則會得到此結果。但是,我現在已經過了大約500次這個事情了,他們都同意。什麼/其他/導致此?

背景:這是VS 2010項目從VS 2008只轉換

MFC工具箱Library.lib設置爲編譯爲靜態庫,使用/ MTD,如.EXE我想目標在此解決方案中編譯。此外,從(VS 2008)轉換而來的解決方案已正確編譯&鏈接!因此,這兩個.vcproj之間並不存在分歧 - 或者至少在轉換之前沒有分歧​​。另外,另一個解決方案中約25個其他項目使用MFC工具箱庫 - 並且在該解決方案(主版本英語)中,它編譯&針對這些其他項目的鏈接,無需在調試和發佈目標中投訴。

我剛剛花了最後一個小時去了解這個目標項目(Cimex Header Viewer)的每個項目屬性與主構建英語解決方案中的幾個不同的目標exe項目 - 我找不到差異。它們似乎是相同的,除了它們是不同的名稱。

我試過做一個乾淨的&建立所有。我完全沒有想法。

有沒有人有想過還有什麼我可以研究?

我想我已經準備好開始咀嚼玻璃了。 :(

+0

嗯,它說你(或者是微軟?)已經以某種方式在[SimpleFileIO.obj]的wcslen_s中編譯,沒有被丟棄,即在C++級別沒有「內聯」。嘗試右鍵單擊wcsnlen和「定義」。如果它是「內聯」=神祕。 – 2011-01-11 20:49:12

+0

我發現我定義的wcsnlen函數實際上是內聯的。因此,連接器擁有訪問SimpleFileIO.obj內嵌定義,與一個是CRT的一部分衝突。去搞清楚! – Mordachai 2011-01-11 21:21:16

回答

0

抱歉浪費大家的時間。你的答案是萬事的種種,我一直在看,雖然我還沒有真正使用/ verbose選項,並會考慮在將來。

然而,這一個歸結爲這樣的事實:與VS 2010提供的CRT定義了函數wcsnlen()而在2008年的CRT確實。所以我在我的MFC工具箱庫的.h文件,這顯然是從來沒有在任何我的項目是在較大的(53個項目)解決方案「主構建英語」提到的一個提供的wcsnlen()內聯執行。因此,儘管主人建立了&正確鏈接,但它的確如此,只是因爲該功能在這53個子項目中從未被任何東西調用!

但這其他解決方案(溫帶頭查看器)做管理的簡單文件來調用一些IO部分或MFC工具箱,它被稱爲wcsnlen,造成編譯器在SimpleFileIO.obj創建定義爲它後來與衝突2010年的CRT &因此是錯誤信息。

唉...這是要弄清楚,因爲我一直在尋找的項目設置以爲這已經是罪魁禍首(因爲我是從2008 - > 2010轉換項目)疼痛。但問題是確實存在定義符號的衝突,因爲MS在其較新的CRT中突然提供了該函數的defn。

再次 - 抱歉浪費任何人的時間。希望別人會發現這個Q & A的使用。 ;)

1

也許一個項目鏈接到靜態MFC和其他使用它作爲一個DLL ?

+0

我測試過很多次,並會排除該解決方案在2008年 – Mordachai 2011-01-11 21:03:22

3

每當我遇到這個問題,我還沒有明確的線索,我用/ verbose選項(見http://msdn.microsoft.com/en-us/library/wdsk6as6%28v=vs.80%29.aspx詳情)。此選項的輸出可以是巨大的,鏈接,但你會看到哪個對象文件導致哪些其他來自哪個庫的對象文件被包含在鏈接過程中。

我曾經一個典型的例子如下:

我想在一個靜態鏈接的應用程序完全否決C和C++的內存分配函數(動態鏈接是更難)。我開始編寫我自己的malloc和free的實現,然後在鏈接到C/C++庫之前鏈接這個目標文件。

當然,連接器抱怨一些符號(如malloc_nh或類似的東西)被多次定義。使用/ verbose選項,我可以發現,有跡象表明使用中出現的微軟定義自己的malloc和free函數同一個目標文件在其他功能上的目標文件。我只需將這些添加到我的「推翻」實施中並重新鏈接即可。

+0

+1好的建議 – 2011-01-11 21:00:14

相關問題