LNK2022 y LNK2034 errores de enlace con la versión 10.0 del CRT

Question

Siento molestar a nadie con esta pregunta, pero he estado investigando esto durante horas, sin embargo resolución:

Estoy portar una aplicación bastante masivo para el 10.0 CRT (compilador) en Visual Studio 2010. La aplicación se administra C++/CLI que usa/clr. La mayoría del código es nativo (95%), con algunas porciones administradas aquí y allá.

Así que mi trabajo consiste en hacer el cambio en el .vcxproj para apuntar al nuevo 10.0 CRT (es decir, el compilador). Anteriormente estábamos usando v90 o usando el compilador de VC que venía con VS 2008 SP1.

Ok, ¿por qué se están produciendo cambios? Parece un montón en realidad. Arreglé algunos problemas de los iteradores relacionados con los conjuntos, y todo fue muy fácil.

Pero estos errores del enlazador me están matando. Cualquier ayuda se agradece:

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) 

seguí adelante y sin decorar el símbolo:

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

y tengo:

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

Así que, como yo lo entiendo, el archivo msvcmrtd.lib tiene este std :: allocator compilado de una manera, y algo más en la configuración de mi proyecto (#pragma managed ??) se compila de otra manera. Pero si es así, ¿qué busco? Esto ha estado compilando bien durante años usando los viejos compiladores.

Nota: En este momento el marco .NET 3.5 (no estoy seguro si eso ayuda o no ... lo dudo)

Gracias

Answer 1

Este es un problema difícil de diagnosticar, los errores de enlace hedor y están mal documentados. Hay una publicación de Stephan Lavavej, el mantenedor de STL en Microsoft al respecto en el this thread, en la parte inferior de la página. Debo decir que no veo muchos consejos, más allá de intentar deshabilitar la depuración de iteradores en la configuración de su proyecto (_HAS_ITERATOR_DEBUGGING = 0 en las definiciones de preprocesador).

Necesita considerar una revisión del código. Seguro que parece que está compilando el código STL en el código administrado. Eso funciona en general (menos la molestia del enlazador) pero es realmente lo incorrecto de hacer. Deje las clases de colección STL a su código nativo, use las clases de colección BCL (Lista <> etc.) en su código administrado.

Answer 2

En mi caso, lo que ayudó fue el cambio de la TargetFramework en el .VCXPROJ a:

<TargetFrameworkVersion>v4.0</TargetFrameworkVersion> 

Pero como se ha mencionado que necesita para compilar contra 3.5 No estoy seguro de lo que puede hacer en ese caso.

Answer 3

Recientemente migré un proyecto VS2008 a VS2012 que incluía un proyecto C++/cli y experimenté estos errores. Soy bastante atento anal cuando se trata de mis proyectos/archivos de compilación, así que configuré algunos archivos personalizados mspro .props que todos los proyectos importan (para evitar todos los elementos repetidos y condicionados en el XML de msbuild).

Supongamos que el proyecto fue Example.vcxproj.y cerca de la salida he tenido esto:

<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" /> 

tuve mi archivo FileWithCommonSettings.props (donde he definido -TargetFrameworkVersion-) está incluido Microsoft.Cpp.props -after-. En su lugar, opté por probar la configuración -TargetFrameworkVersion- antes de Cpp.props, como se puede ver en el XML comentado. Hacer esto solucionó todos los problemas del enlazador que estaba obteniendo. Supongo que Cpp.Default.props se establece de manera predeterminada en v4.0 en VS2010 y posterior.

Esperanza esto ayuda

edición: Refering to this social.msdn thread, parecería que necesita para usar VS2010 (es decir, v100 conjunto de herramientas) con el fin de orientar realidad v3.5. No me di cuenta de que estaba apuntando silenciosamente a 4.0 todavía con vc110 ... pero fue solo después de que agregué ese elemento -TargetFrameworkVersion- que me deshice de los errores del enlazador. Después de cambiar al conjunto de herramientas vc100, volvieron los errores del enlazador.

Answer 4

Aunque mi solución a este problema no resuelve por qué sucede, estoy haciendo mis observaciones en caso de que alguien más se encuentre con mi misma situación.

Yo también recibí errores similares compilando mi proyecto clr. Mi objetivo era actualizar mi versión a 11.0, pero retener .NET framework 2.0 como objetivo. En mi caso, vi los errores Lnk2034 y lnk2020 (diferentes de los de lnk2022 mencionados anteriormente).

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

Inicialmente, estaba siguiendo los consejos de Hans Passat al corregir el uso de los contenedores nativos en este proyecto. Cometí todas las instancias de esos contenedores para verificar que realmente fueran la causa de la falla.

Durante la investigación, he descubierto que la siguiente línea hizo que mi error:

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

el momento en que se corrigió a la siguiente, esos errores se fue.

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

No hay idea de por qué una línea así causaría este comportamiento, pero lo hizo.

Nota al margen:

• Orientación de un marco .NET superior (4.0) también trabajó, pero quería pegarse a apuntar el marco original de .NET 2.0.
• Mi proyecto no tiene la definición preprecossor: _HAS_ITERATOR_DEBUGGING = 0. A mi entender, la compilación _HAS_ITERATOR_DEBUGGING en/CLR ya no es compatible (ver enlace en la respuesta de Hans Passat)

Answer 5

para cualquier persona como yo que esta respuesta no suene muy útil, una segunda opción es ir a:. Proyecto Propiedades-> Configuración Propiedades-> General-> Valores predeterminados del proyecto -> NET Framework versión Target y ponerlo a v4.0

https://connect.microsoft.com/VisualStudio/feedbackdetail/view/806238/unwarranted-linker-errors-using-stl-filestream-class-in-managed-classes-in-c-11-cli tiene una respuesta oscura de Mi equipo de crosoft que solucionó mi problema.