CRT 10.0 版的 LNK2022 和 LNK2034 链接器错误答案

【问题标题】：LNK2022 and LNK2034 linker errors with version 10.0 of the CRTCRT 10.0 版的 LNK2022 和 LNK2034 链接器错误
【发布时间】：2011-04-06 22:49:28
【问题描述】：

很抱歉用这个问题打扰任何人，但我已经研究了几个小时，还没有解决方案：

我正在将一个相当庞大的应用程序移植到 Visual Studio 2010 中的 10.0 CRT（编译器）。该应用程序是使用 /clr 的托管 C++/CLI。大部分代码是本机代码 (95%)，其中有一些托管部分。

所以我的工作是在 .vcxproj 中进行切换以针对较新的 10.0 CRT（即编译器）。我们之前使用的是 v90，或者使用的是 VS 2008 SP1 附带的 VC 编译器。

好的，那么重大更改？好像真的是一堆。我修复了一些处理集合的迭代器问题，这一切都很容易。

但是这些链接器错误正在杀死我。任何帮助将不胜感激：

1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001c0).
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001c5).
...

1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2034: metadata inconsistent with COFF symbol table: symbol '??0?$allocator@D@std@@$$FQAE@ABV01@@Z' (06000141) has inconsistent metadata with (0A000F75) in identity.obj
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2034: metadata inconsistent with COFF symbol table: symbol '??0?$allocator@D@std@@$$FQAE@ABV01@@Z' (06000141) has inconsistent metadata with (0A000F76) in ICustAttribCollapseManagerImp.obj
... (repeated hundreds of times)

我继续并没有装饰符号：

??0?$allocator@D@std@@$$FQAE@ABV01@@Z

得到：

public: __thiscall std::allocator<char>::allocator<char>(class std::allocator<char> const &)

因此，据我了解，msvcmrtd.lib 文件以一种方式编译了此 std::allocator，而我的项目设置中的其他内容（#pragma managed ??）以另一种不同的方式编译。但如果是这样，我要寻找什么？使用旧编译器多年来一直可以很好地编译。

注意：我们目前是 3.5 .NET 框架（不确定这是否有帮助......我对此表示怀疑）

谢谢

【问题讨论】：

标签： windows visual-studio-2010 winapi stl linker-errors

【解决方案1】：

这是一个难以诊断的问题，链接器错误很臭，并且记录不充分。微软的 STL 维护者 Stephan Lavavej 在页面底部的this thread 中有一篇关于它的帖子。我不得不说，除了尝试在项目设置中禁用迭代器调试（预处理器定义中的_HAS_ITERATOR_DEBUGGING = 0）之外，我没有看到太多建议。

您确实需要考虑进行代码审查。看起来您正在将 STL 代码编译为托管代码。这通常有效（减去链接器的麻烦），但这确实是错误的做法。将 STL 集合类留给您的本机代码，在您的托管代码中使用 BCL 集合类（List 等）。

【讨论】：

这是一头野兽。即使您在 MSDN 上链接到的那个线程也没有什么可提供的。我会试试你建议的预处理器，然后回到这个线程，明天让你知道。
尝试设置预处理器，没有成功。太糟糕了，写所有这些东西的开发人员不再为我的公司工作了，我只能收拾残局了。不过感谢您的帮助。
我将把它标记为答案，因为在您提供的链接中，Lavavej 先生指出 std::string 类现在仅在 VC 10.0 和大多数（如果不是全部）中是标题我的链接器错误与字符串问题有关。虽然我还没有解决这个问题。
MSDN Visual C++ 团队网站上的此博客条目提供了一种未记录的方式来诊断链接器错误 2022：blogs.msdn.com/b/vcblog/archive/2007/05/17/…
已解决：通过仅在 (~12) 个需要它的文件上设置 /clr 开关，并为整个项目关闭 /clr。

【解决方案2】：

对于像我这样的人，这个答案没有帮助，第二个选择是去： Project Properties->Configuration Properties->General->Project Defaults->.NET Target Framework Version并将其设置为v4.0

https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli 有一个来自 Microsoft 团队的晦涩答案，解决了我的问题。

【讨论】：

这对我有用 - 在 VS2019 16.11.10 中使用 .NET 3.5 Framework；更改为 4.0 修复了错误

【解决方案3】：

在我的情况下，将 .VCXPROJ 中的 TargetFramework 更改为：

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

但正如您所提到的，您需要针对 3.5 进行编译，我不确定在这种情况下您可以做什么。

【讨论】：

【解决方案4】：

我最近将一个 VS2008 项目迁移到 VS2012，其中包含一个 C++/cli 项目并遇到了这些错误。当涉及到我的项目/构建文件时，我非常顽固，所以我设置了一些项目都从中导入的自定义 .props msbuild 文件（以避免 msbuild XML 中所有重复的和条件混乱的元素）。

所以假设项目是 Example.vcxproj。在开始时我有这个：

<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Label="Configuration">
  <ConfigurationType>DynamicLibrary</ConfigurationType>
  <PlatformToolset>v110_xp</PlatformToolset>
  <CharacterSet>Unicode</CharacterSet>
  <CLRSupport>true</CLRSupport>
  <-- Including this here fixed my linker problems -->
  <!--<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>-->
</PropertyGroup>
...
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
...
<Import Project="$(SolutionDir)..\shared\config\msbuild\FileWithCommonSettings.props" />

我在 Microsoft.Cpp.props 之后包含了我的 FileWithCommonSettings.props 文件（我在其中定义了 -TargetFrameworkVersion-）。相反，我选择尝试在 Cpp.props 之前设置 -TargetFrameworkVersion-，正如您在注释掉的 XML 中看到的那样。这样做解决了我遇到的所有链接器问题。我的猜测是 Cpp.Default.props 在 VS2010 及更高版本中默认为 v4.0。

希望对你有帮助

编辑：Refering to this social.msdn thread，看来您需要使用 VS2010（即工具集 v100）才能真正定位 v3.5。我没有意识到我仍然在使用 vc110 默默地瞄准 4.0……但只有在我添加了 -TargetFrameworkVersion- 元素之后，我才摆脱了链接器错误。切换到 vc100 工具集后，链接器错误又回来了。

【讨论】：

【解决方案5】：

虽然我对这个问题的解决方案没有说明它发生的原因，但我注意到我的观察，以防其他人遇到我的相同情况。

我在编译我的 clr 项目时也收到了类似的错误。我的目标是将我的版本升级到 11.0，但保留 .NET Framework 2.0 作为目标。就我而言，我看到了 Lnk2034 和 lnk2020 错误（与上面提到的 lnk2022 不同）。

1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2034: metadata inconsistent with COFF symbol table: symbol '?_Facet_Register_m@std@@$$FYAXPAV_Facet_base@1@@Z' (06000068) has inconsistent metadata with (0A000C23) in DirectSystemAccessProxy.obj
1>LINK : error LNK2034: metadata inconsistent with COFF symbol table: symbol '??3@$$FYAXPAX@Z' (060003CB) has inconsistent metadata with (0A00009D) in MSVCMRTD.lib(locale0_implib.obj)
...
1>myProject.obj : error LNK2020: unresolved token (0A000C23) "void __cdecl std::_Facet_Register_m(class std::_Facet_base *)" (?_Facet_Register_m@std@@$$FYAXPAV_Facet_base@1@@Z)
1>MSVCMRTD.lib(locale0_implib.obj) : error LNK2020: unresolved token (0A0000C4) "extern "C" void __cdecl free(void *)" (?free@@$$J0YAXPAX@Z)
...

最初，我遵循 Hans Passat 的建议，在此项目中更正了本机容器的使用。我注释掉了这些容器的所有实例，以验证它们确实是失败的原因。

在调查过程中，我发现以下行导致了我的错误：

std::wstringstream wstream;
wstream << " Failed to to do something \'" << var << "\'.";

当我将其更正为以下内容时，这些错误就消失了。

std::wstringstream wstream;
wstream << L" Failed to to do something \'" << var << L"\'."; // Added wide string literal.

不知道为什么这样的一行会导致这种行为，但确实如此。

旁注：

针对更高版本的 .NET 框架 (4.0) 也有效，但我想坚持针对 2.0 的原始 .NET 框架。
我的项目没有 preprecossor 定义：_HAS_ITERATOR_DEBUGGING = 0。据我了解，不再支持在 /clr 中编译 _HAS_ITERATOR_DEBUGGING（请参阅 Hans Passat 答案中的链接）

【讨论】：