windows - LNK2022 og LNK2034 linkerfejl med version 10.0 af CRT

Indlæg af Hanne Mølgaard Plasc

Problem



Undskyld at forstyrre nogen med dette spørgsmål, men jeg har forsket dette i timevis, uden nogen beslutning endnu:


Jeg bærer en temmelig massiv applikation til 10.0 CRT (compiler) i Visual Studio 2010. Appen styres C ++/CLI, der bruger/clr. Det meste af koden er indfødt (95\%), med et par administrerede portioner her og der i den.


Så mit job er at gøre omskifteren i .vcxproj til mål mod den nyere 10.0 CRT (dvs. compiler). Vi brugte tidligere v90, eller ved hjælp af VC compileren, der fulgte med VS 2008 SP1.


Ok, så bryder forandringer? Virker som en flok faktisk. Jeg fastsatte et par iteratorproblemer, der beskæftiger sig med sæt, som alle var alle ganske enkle.


Men disse linkerfejl dræber mig. Enhver hjælp ville blive værdsat:


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)


Jeg gik videre og undecorated symbolet:


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


og fik:


public: \_\_thiscall std::allocator<char>::allocator<char>(class std::allocator<char> const &)


Så som jeg forstår det, har filen msvcmrtd.lib denne std :: allocator samlet på en måde, og noget andet i mine projektindstillinger (#pragma managed?) Er udarbejdet en anden, anderledes måde. Men hvis i så fald, hvad søger jeg efter? Dette har samarbejdet fint i årevis ved hjælp af de gamle kompilatorer.


Bemærk:
Vi i øjeblikket 3.5. NET Framework (Ikke sikker på om det hjælper eller ej ... Jeg tvivler på det)


Tak

Bedste reference


Dette er svært at diagnosticere problem, linkerfejlne stinker og er dårligt dokumenterede. Der er et indlæg fra Stephan Lavavej, STL maintainer hos Microsoft om det i denne tråd nederst på siden. Jeg må sige, at jeg ikke ser meget af noget råd i det, ud over at forsøge at deaktivere iterator debugging i dine projektindstillinger (\_HAS\_ITERATOR\_DEBUGGING=0 i præprocessor-definitionerne). [9]


Du skal overveje en kode anmeldelse. Det ser ud til at du udarbejder STL-kode i administreret kode. Det virker generelt (minus linker besværet), men det er virkelig den forkerte ting at gøre. Lad STL-samlingsklasserne overgå til din oprindelige kode, brug BCL-samlingsklasserne (List <> etc) i din administrerede kode.

Andre referencer 1


I mit tilfælde var det, der hjalp, at ændre TargetFramework i .VCXPROJ til:


<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>


Men som du har nævnt skal du kompilere mod 3.5, er jeg ikke sikker på hvad du kan gøre i det tilfælde.

Andre referencer 2


Jeg har for nylig migreret et VS2008-projekt til VS2012, der omfattede et C + +/Cli-projekt og oplevede disse fejl. Jeg er temmelig anal tilbageholdende når det kommer til mine projekt/build-filer, så jeg opsætter nogle brugerdefinerede .props msbuild-filer, som projekterne alle importerer fra (for at undgå alle de gentagne og betingede elementer i msbuild XML).


Så lade ud som om projektet var Example.vcxproj. og i starten havde jeg det her:


<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)..sharedconfigmsbuildFileWithCommonSettings.props" />


Jeg havde min FileWithCommonSettings.props-fil (hvor jeg har -TargetFrameworkVersion-defined) inkluderet -after- Microsoft.Cpp.props. Jeg valgte i stedet at prøve at indstille -TargetFrameworkVersion- før Cpp.props, som du kan se i XML-kommentaren. Gør dette fast alle de linker problemer, jeg fik. Mit gæt er, at Cpp.Default.props er standard til v4.0 i VS2010 og senere.


Håber dette hjælper


Rediger : Når du henviser til denne social.msdn-tråd, ser du ud til, at du skal bruge VS2010 (dvs. værktøjssættet v100) for faktisk at målrette mod v3.5. Jeg var ikke klar over, at jeg stilte målrettet 4.0 stadig med vc110 ... men det var først efter at jeg tilføjede, at -TargetFrameworkVersion-elementet slapede jeg af linkerfejlene. Efter at skifte til vc100 værktøjssættet kom linkerfejlene tilbage. [10]

Andre referencer 3


Selvom min løsning på dette problem ikke omhandler hvorfor det sker, bemærker jeg mine bemærkninger, hvis nogen andre kommer over mit samme scenario.


Jeg har også modtaget lignende fejl sammen med min clr-projekt. Mit mål var at opgradere min version til 11,0, men behold. NET Framework 2.0 som mål. I mit tilfælde så jeg Lnk2034 og lnk2020 fejl (forskellig fra lnk2022 bemærket ovenfor).


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)
...


I begyndelsen fulgte jeg Hans Passats råd ved at korrigere brugen af ​​de indfødte beholdere i dette projekt. Jeg kommenterede alle forekomster af disse containere for at verificere, at de faktisk var årsagen til fejl.


Under undersøgelsen opdagede jeg, at følgende linje forårsagede min fejl:


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


I det øjeblik jeg rettede det til følgende, gik disse fejl væk.


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


Ingen anelse om, hvorfor en sådan linje ville forårsage denne adfærd, men det gjorde det.


Side Bemærk:



  • Målretning af en højere .NET-ramme (4.0) fungerede også, men jeg ønskede at holde fast i at målrette mod den oprindelige .NET-ramme af 2.0.

  • Mit projekt havde ikke preprecossor definitionen: \_HAS\_ITERATOR\_DEBUGGING=0. Efter min forståelse er kompilering af \_HAS\_ITERATOR\_DEBUGGING i/clr ikke længere understøttet (Se link i Hans Passats svar)


Andre referencer 4


for alle som mig, at dette svar ikke ringede nyttigt, er en anden mulighed at gå til:
Projektegenskaber-> Konfigurationsegenskaber-> Generelt-> Projektstandarder -> .NET Målrammerversion og sæt det til v4.0


https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli har et uklart svar fra Microsoft-team, der fik mit problem. [11]