visual-studio - LNK2019 错误在 VS6.0 -> VS2013 迁移 MFC DLL 项目

Question

尝试将大型 VS6.0 DLL 项目构建/移植到 VS2013 时出现以下链接错误，其中 DLL 模块依赖于其他 DLL 模块。未定义函数的独特之处在于它接受 CString 参数，但也许问题比这更明显:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall CTokenEx::Split(class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class CStringArray &,int)" (__imp_?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z) referenced in function "public: bool __thiscall OptionFlag::isTestEnableByFlag(class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >)" (?isTestEnableByFlag@OptionFlag@@QAE_NV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@@Z)

这是导出符号的模块的 dumpbin.exe(来自 *.exp 文件):

 00000148  DIR32NB                    00000000        20  $N00027
 00000094  DIR32NB                    00000000        4F  ?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z (public: void __thiscall CTokenEx::Split(class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class ATL::CStringT<char,class StrTraitMFC_DLL<char,class ATL::ChTraitsCRT<char> > >,class CStringArray &,int))
 0000014C  DIR32NB                    00000000        21  $N00028

这是 *.lib 文件的转储，我在 *.lib 文件中看到 __imp_。

     3E30 ?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z
     3E30 __imp_?Split@CTokenEx@@QAEXV?$CStringT@DV?$StrTraitMFC_DLL@DV?$ChTraitsCRT@D@ATL@@@@@ATL@@0AAVCStringArray@@H@Z

当然，我需要再次检查我正在阅读的 this 与/Verbose 告诉我的 .exp/.lib 完全一致。

在这种特殊情况下，我遇到的所有问题都是 DLL“x”引用 DLL“y”中的函数，该函数具有 CTokenEx::Split() 函数，该函数具有 CString 参数。我认为问题出在 CSTring MFC 与 ATL 声明(请参阅下面的链接)，现在我不太确定，所以在此处发布后回到第一个问题。 (也就是说，这是我漏掉的错字吗？DOH？)

我已完成以下操作以找出问题所在构建属性:

1. 已验证所有模块都使用 MBCS(多字节字符集)而非 Unicode
   
2. 已验证所有模块都在使用“在 DLL 中使用 MFC”进行构建
3. 使用/Verbose 和 Verbose:lib 运行链接器以验证链接器是否引用了我预期的链接文件。
4. 使用 dumpbin.exe 检查导出的符号装饰以查看它们是否被导出。 (我认为他们是，但我不是垃圾箱专家)。
5. 找到了这些可能相关的链接:
   MSDN LNK2019 error并尝试对 CString 类型的 dllimport 进行硬编码。
   link关于 MFC 和 CRT CSTring 定义。不能 100% 确定这是问题所在。 (可能是我在论点中遗漏的东西。)
   
6. 包含“afxstr.h”，并强制使用 -D“_MFC_DLL_BLD”

我正在使用的 DLL 模块的 CTokenEx 部分似乎来自 here但我还没有证实。目前，我不确定这是否相关。

我只是想确认我对 dumpbin.exe 的分析是准确的，它告诉我符号导出正确。我认为这可能是一个链接顺序问题，并第二次将 DLL 引用到链接器，但这没有帮助。前世曾在 SunOs 中处理类似的链接器问题(回到远古时代)。

如果我解决了这个问题，我会发布这个问题的答案。

Answer 1

!DOH!消除所有其他选项后。 .尽管使用/Verbose 和/Verbose:lib 会向您显示 *.lib 文件的位置，并确认已找到它们，但您必须注意!在我的例子中，“.”中有一些 VS6.0 STALE *.lib 文件。相对于解决方案工作区和链接器首先找到那些，当然它们可能没有正确装饰符号。如果链接器告诉您它链接在:
我的lib.lib而不是
路径\to\Mylib.lib这是一个主要线索:)。

Sooo...我认为这是一个复杂而奇怪的链接器问题。是一个!DOH!简单的链接器问题。

问题解决了，就这么简单。