Ошибки компоновщика LNK2022 и LNK2034 с версией 10.0 CRT

Question

Извините, что беспокою кого-либо с этим вопросом, но я исследовал это в течение нескольких часов, пока без разрешения:

Я портирую довольно масштабное приложение на CRT 10.0 (компилятор) в Visual Studio 2010. Приложение управляется C ++ / CLI, использующим / clr. Большая часть кода является родной (95%), с несколькими управляемыми частями здесь и там.

Таким образом, моя работа состоит в том, чтобы сделать переключение в .vcxproj для нацеливания на более новую 10.0 CRT (т.е. компилятор). Ранее мы использовали v90 или компилятор VC, поставляемый с VS 2008 SP1.

Ладно, так что сломать изменения? Похоже, куча на самом деле. Я исправил несколько проблем с итераторами, связанных с наборами, и все было довольно просто.

Но эти ошибки компоновщика убивают меня. Любая помощь будет оценена:

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 Framework (Не уверен, помогает ли это или нет ... Я сомневаюсь в этом)

Спасибо

Answer 1

Это трудно диагностируемая проблема, ошибки компоновщика воняют и плохо документированы.Есть сообщение от Стефана Лававея, сопровождающего STL в Microsoft, об этом в этой теме , внизу страницы.Я должен сказать, что не вижу в этом особого совета, кроме попыток отключить отладку итератора в настройках вашего проекта (_HAS_ITERATOR_DEBUGGING = 0 в определениях препроцессора).

Вам необходимо рассмотреть пересмотр кода,Похоже, вы компилируете код STL в управляемый код.Это работает в целом (без проблем с компоновщиком), но это действительно неправильная вещь.Оставьте классы коллекции STL для своего собственного кода, используйте классы коллекции BCL (List <> и т. Д.) В своем управляемом коде.

Answer 2

В моем случае мне помогло изменение TargetFramework в .VCXPROJ на:

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>

Но, как вы упомянули, вам нужно скомпилировать с 3.5, я не уверен, что вы можете сделать в этом случае.

Answer 3

для любого, как я, что этот ответ не прозвучал полезным, второй вариант - перейти по адресу: Свойства проекта-> Свойства конфигурации-> Общие-> Параметры проекта по умолчанию -> .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, который исправил мою проблему.

Answer 4

Хотя в моем решении этой проблемы не указано, почему это происходит, я отмечаю свои наблюдения на случай, если кто-нибудь еще столкнется с моим сценарием.

Я тоже получил похожие ошибки при компиляции моего проекта 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)
...

Изначально я следовал совету Ханса Пассата, исправляя использование собственных контейнеров в этом проекте.Я прокомментировал все экземпляры этих контейнеров, чтобы убедиться, что они действительно являются причиной сбоя.

В ходе расследования я обнаружил, что моя ошибка вызвала следующая строка:

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) также работала, но я хотелпридерживаться целевой исходной платформы .NET 2.0.
• В моем проекте не было определения препрекорсора: _HAS_ITERATOR_DEBUGGING = 0. Насколько я понимаю, компиляция _HAS_ITERATOR_DEBUGGING в / clr больше не поддерживается (см. ссылку в Hans Passat'sответ)

Answer 5

Я недавно перенес проект VS2008 в VS2012, который включал проект C ++ / cli, и столкнулся с этими ошибками.Я довольно любезен, когда дело доходит до файлов моего проекта / сборки, поэтому я настраиваю некоторые пользовательские файлы .props msbuild, из которых импортируются все проекты (чтобы избежать всех повторяющихся и условных элементов в XML-файле msbuild).

Итак, представьте, что проект был 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" />

У меня был файл FileWithCommonSettings.props (где у меня определен -TargetFrameworkVersion-), который был включен после Microsoft.Cpp.props.Вместо этого я решил попробовать установить -TargetFrameworkVersion- перед Cpp.props, как вы можете видеть в закомментированном XML.Это исправило все проблемы с компоновщиком, которые я получал.Я предполагаю, что Cpp.Default.props по умолчанию v4.0 в VS2010 и позже.

Надеюсь, что это поможет

edit : Ссылаясь на этот социальный.msdn thread , может показаться, что вам нужно использовать VS2010 (т. е. набор инструментов v100), чтобы фактически нацелиться на v3.5.Я не осознавал, что нацелился на 4.0 все еще с vc110 ... но только после добавления элемента -TargetFrameworkVersion- я избавился от ошибок компоновщика.После переключения на набор инструментов vc100 вернулись ошибки компоновщика.