2013-12-14 48 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进行混合和匹配,那将会很好。这种问题并不罕见,对于解决方案的线索必须是链接器所抱怨的名称中缺少或增加的下划线,这对我来说毫无意义。 –