2013-12-14 47 views
1

我正在使用vs2012創建一個小包裝DLL,鏈接到用VC6構建的另一個DLL(.lib)。鏈接到vc6時未解決的符號dll/lib

我得到這樣的鏈接錯誤:

error LNK2019: unresolved external symbol [email protected] 

我添加了VC6的dll到鏈接線提供的庫文件,正如我在過去所做的那樣......有一些版本問題就在這裏?在VC6 DLL頭文件在我認爲是標準的方式聲明功能:

#define DLLIMPORT extern "C" __declspec(dllimport) 
DLLIMPORT ULONG WINAPI functionName(...); 

使用DUMPBIN /在VC6庫文件出口顯示「functionName」沒有小鬼前綴和「@ 8」 ..不知道這是一個問題,或者只是對我來說,只是dumpbin對我很好,並且對我有影響。

我不是一個Windows的人,不知道爲什麼鏈接器沒有找到符號...幫助!

+0

發回來,你不想要它。您必須刪除DLLIMPORT和WINAPI,但如果該文件出現在.h文件中,則該文件不太可能正確。 –

+0

恩,感謝您的評論,但爲什麼我必須刪除DLLIMPORT和WINAPI? DLLIMPORT告訴編譯器/鏈接器,我正在引用的函數將在dll中提供,這是正確的。 WINAPI是調用約定,也是正確的.. –

+0

DLLIMPORT說DLL有一個* extra *導出,其名稱以__imp開頭。 WINAPI說調用約定是__stdcall,它會產生額外的@ 8。由於您無法使用dumpbin.exe找到這些文件,因此您希望將其發回,這對您沒有任何用處。 –

回答

3

解決!有兩個問題:

1)dumpbin/exports不顯示所有的符號。使用/ all替代顯示形式爲__imp_functionName @ 8的符號。

2)鏈接器正在尋找由vc6 lib提供的__imp__而不是__imp_的符號。谷歌告訴我,這是32位和64位版本之間的區別,所以vc6庫是64位版本,而我的32。

更改我的包裝DLL 64位解決了問題!

這是花了半天的時間!也許。可能不會。當我喜歡做一名程序員時,就像這樣的時代!

+0

一個64位的VC6庫?我想,當x64剛剛起步時,可能會有一個針對'cl.exe' 12.xx的amd64目標版本隨某些Windows SDK分發。但即使該編譯器確實存在,看起來像用它構建的庫也不太可能需要今天處理。 –

+1

導入庫頭文件聲稱編譯器是vc6 ...我不知道。現在就開始工作吧。 –

+0

有趣。我認爲如果鏈接器可以讓您知道何時將x64與x86進行混合和匹配,那將會很好。這種問題並不罕見,對於解決方案的線索必須是鏈接器所抱怨的名稱中缺少或增加的下劃線,這對我來說毫無意義。 –