Error de enlace: xxx ya está definido en *****. LIB :: ¿Qué es exactamente lo que está mal?

Question

Problema:

Estoy tratando de utilizar una biblioteca denominada DCMTK que utilizó algunas otras bibliotecas externas (zlib, libtiff, libpng, libxml2, libiconv). He descargado estas bibliotecas externas (* .LIB & * .h archivos) desde el mismo sitio web. Ahora, cuando compilo la biblioteca DCMTK estoy recibiendo errores de enlace (793 errores) así:

Error 2 error LNK2005: __encode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error 3 error LNK2005: __decode_pointer already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error 4 error LNK2005: __CrtSetCheckCount already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error 5 error LNK2005: __invoke_watson already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error 6 error LNK2005: __errno already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error 7 error LNK2005: __configthreadlocale already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 
Error 8 error LNK2005: _exit already defined in MSVCRTD.lib(MSVCR90D.dll) LIBCMTD.lib dcmmkdir 

Documentación:

Esto parece ser un error popular para esta biblioteca es así, que hacen tener una entrada de la FAQ abordar esta cuestión, que (http://forum.dcmtk.org/viewtopic.php?t=35) dice:

• el problema es que el enlazador intenta combinar diferente, versiones incompatibles de Visual Biblioteca de tiempo de ejecución C++ en un solo binario.
• Esto sucede cuando no se generan todas las partes de su proyecto y las bibliotecas con las que se establece con las mismas opciones de generación de código en Visual C++.

• No utilice la solución/NODEFAULTLIB, porque pueden producirse extraños errores del software . ¡Arreglar el problema!

• DCMTK es por defecto compilado con la opción "multiproceso" o "multiproceso depuración" generación de código (la último para el modo de depuración).

• Cambie la configuración del proyecto de la totalidad de su código para utilizar estas opciones de generación de código ,
• o cambiar la generación de código para todos los módulos DCMTK y re-compilación.
• usuarios MFC cuidado: DCMTK debe ser compilado con "multiproceso DLL" o "multiproceso DLL de depuración" ajustes si que desea vincular las bibliotecas en una aplicación MFC .

Solución al mismo problema para los demás:

Huge Amount of Linker Issues with Release Build Only dice:

Parece que su versión de lanzamiento es tratar de vincular a algo que era depuración incorporado. Es probable que tengas una dependencia rota en tu compilación, (o perdiste reconstruir algo al liberar a mano si tu proyecto es normalmente construido en piezas).

Más técnicamente, que parecen ser vincular los proyectos construidos con diferentes configuraciones C Run Time library, uno con "Multi-threaded", otra con "Multi-roscado de depuración".Ajuste la configuración de todos los proyectos a utilizar el mismo sabor de la biblioteca y el problema debería desaparecer

Preguntas:

Hasta ahora solía pensar que Nombre mangling es la único problema que puede causar fallas de enlace si no se ha estandarizado. Justo ahora sabía que hay otras cosas que también pueden causar el mismo efecto.

1. ¿Cuál es hasta con el "modo de depuración" (multihilo de depuración) y "Modo Release" (multihilo)? ¿Qué exactamente está sucediendo debajo del capó? ¿Por qué exactamente esto está causando un error de enlace?

2. Me pregunto si hay algo llamado "Single-Threaded Debug" y "Single-Threaded" que nuevamente causa lo mismo.

3. La documentación habla sobre "Opciones de generación de código". ¿Qué opciones de generación de código? WTH son ellos?

4. La documentación nos advierte específicamente de no utilizar la solución/NODEFAULTLIB. (ejemplo/NODEFAULTLIB: msvcrt). ¿Por qué? ¿Cómo causaría problemas? que es exactamente?

5. Explique el último punto de la documentación para usuarios de MFC. Porque voy a usar MFC más adelante en este proyecto. Explica por qué deberíamos hacerlo? ¿Qué problemas causaría si no lo hago?
6. ¿Algo más que quiera mencionar? Me refiero a errores similares. Estoy muy interesado en Linker & sus problemas. Entonces, si hay algo similar, puede mencionarlos o algunas palabras clave al menos.

Answer 1

¿Cuál es hasta con el "modo de depuración" (multihilo de depuración) y "Release Mode" (multihilo)? ¿Qué exactamente está sucediendo debajo del capó?¿Por qué exactamente esto está causando el error de vinculación ?

El enlazador se arrastra en las bibliotecas por varias razones diferentes. Lo más simple es que una biblioteca aparece en la línea de comando del enlazador, o en el archivo de respuesta del enlazador en la línea de comando del enlazador. Pero cualquier archivo objeto, ya sea compilado en su proyecto o empaquetado en una biblioteca, también puede contener linker options, incluyendo solicitar que se vinculen bibliotecas particulares. De hecho, el compilador de Visual C++ incrusta automáticamente tales opciones de enlazador que coinciden con las opciones de proyecto que utiliza al compilar.

En el tiempo del enlace, se combinan todas las opciones del vinculador de todos los objetos y archivos de objetos en archivos de biblioteca estáticos. Si se solicita más de un nombre de archivo de biblioteca CRT, el vinculador lee en todos ellos y se obtienen conflictos de nombres, donde el vinculador no sabe cuál usar.

Me pregunto si hay algo que se llama "único subproceso de depuración" y "Single-threaded" que a su vez provoca la misma cosa.

Solía ​​haberlo, pero las últimas versiones de Visual C++ solo han enviado bibliotecas compatibles con múltiples subprocesos.

La documentación habla de "Opciones de generación de código". ¿Qué código opciones de generación? WTH son ellos?

Mire inside your project options.

La documentación nos advierte específicamente para no utilizar/NODEFAULTLIB solución. (example/NODEFAULTLIB: msvcrt). ¿Por qué? ¿Cómo puedo causar problemas? ¿Qué exactamente es?

Si usa/NODEFAULTLIB, se ignorarán todas las configuraciones del vinculador almacenadas dentro de los objetos y objetos en las bibliotecas. Usted terminará sin una biblioteca en tiempo de ejecución y tal vez le falten otras bibliotecas. Puede volver a agregarlos a mano, pero sigue siendo un gran desastre.

Explique el último punto en la documentación para usuarios de MFC. Porque Voy a utilizar MFC más adelante en este proyecto . Explica por qué deberíamos hacerlo? ¿Qué problemas causaría si I no. ¿Algo más que le gustaría mencionar ? Me refiero a errores similares . Estoy muy interesado en Linker & sus problemas. Por lo tanto, si hay cosas similares, puede mencionarlos o algunas palabras clave al menos.

Las aplicaciones MFC y la biblioteca MFC deben utilizar las mismas funciones de administración de memoria, de modo que la memoria asignada por MFC pueda liberarse por la aplicación y viceversa. Los identificadores FILE y otros recursos también se comparten. Los archivos DLL de MFC ya están compilados para utilizar el CRT en un archivo DLL, y para poder compartir recursos, debe usar el mismo CRT, lo que significa que también debe usar un archivo DLL.

Answer 2

¿Cuál es hasta con el "modo de depuración" (multihilo de depuración) y "Modo Release" (multihilo)? ¿Qué está pasando exactamente debajo del capó? ¿Por qué exactamente esto está causando un error de enlace?

Son versiones diferentes de la biblioteca C runtime. Puede vincular estáticamente a la biblioteca de tiempo de ejecución en modo de depuración y liberación. En las Opciones de generación de código (mencionadas a continuación), esas serían "Depuración multiproceso" y "Varias cadenas". Las opciones "DLL de depuración de múltiples subprocesos" y "DLL de subprocesos múltiples" se vinculan dinámicamente con el tiempo de ejecución de C. Al vincular dinámicamente al tiempo de ejecución, también deberá enviar su instalador configurado para instalar el paquete redistribuible de VC que contiene los dlls de tiempo de ejecución adecuados para su versión de Visual C++.

enlazado estático al tiempo de ejecución C está mal generalmente en, incluso por Microsoft:

Además de todos los métodos descritos anteriormente de la distribución de la Visual C++ bibliotecas DLL, hay una última opción para construyendo su aplicación que no requiere para distribuir los archivos DLL.Sin embargo, esta opción sólo funciona para nativo-único código (que no es compatible con/CLR) y deja serio a sus clientes vulnerable a cualquier agujero de seguridad como así como añade una carga significativa sobre mismo que parchear todos los sistemas del cliente si se encuentra una vulnerabilidad en cualquier de las bibliotecas. Esta opción es para vincular estáticamente en las bibliotecas como archivos .lib en lugar de dinámicamente cargarlos como archivos DLL. Haga esto por usando el indicador/MT en la línea de comando cl.exe (vs/MD) o seleccionando la opción apropiada en sus propiedades de proyecto a través de Visual Studio. Usted puede desear utilizar esta opción cuando pruebas de versiones de depuración anticipadas de su aplicación en máquinas de prueba antes de usted comienza a trabajar en la configuración. [Ver nota 3]

Sin embargo, no puedo pensar en ninguna escenarios en que esto es en realidad lo correcto hacer al enviar su producto a los clientes. Básicamente, lo que hace este enfoque es extraer el código binario necesario de los archivos .LIB al compilar el tiempo , convirtiéndolo en una parte de los archivos .exe o .dll. Aumenta el tamaño de su aplicación , y no hay manera de que actualice las bibliotecas aparte de recompilando su aplicación con los nuevos .LIBs y redistribuya su aplicación nuevamente. Lo que esta medios es que a menos que vaya contacto cada máquina que tiene instalada la aplicación cada vez que hay una vulnerabilidad de seguridad encontrado en el Visual C++ bibliotecas y por completo volver a instalar los actualizados binarios, va a dejar su Clientes vulnerables al ataque. Si lugar se utiliza la DLL, cada vez que hay una vulnerabilidad de seguridad encontrado en el Visual C++ bibliotecas, Microsoft va a instalar la actualización centralmente en la carpeta WinSxS través Windows Update y todas las solicitudes de las DLL será redirigido a la versión actualizada . Esto elimina toda la carga mantenimiento de su lado y también permite al usuario instalar una actualización pequeña que tocar todas sus aplicaciones en lugar de reemplazar todos los exe y DLL instalado en su sistema . Por favor, no distribuir una aplicación construida mediante la vinculación de estáticamente contra el Visual C++ bibliotecas a menos que tenga un sistema en el lugar para actualizar cada máquina cliente y también tienen una muy buena razón para hacerlo. En este momento, puedo pensar en ninguna circunstancia bajo la cual esto sería lo correcto para hacer para una aplicación de envío.

---

Me pregunto si hay algo que se llama "único subproceso de depuración" y "Single-threaded" que a su vez provoca la misma cosa.

No existe tal cosa, consulte más arriba.

---

Documentación habla algo sobre "Opciones de generación de código". ¿Qué opciones de generación de código? WTH son ellos?

Haga clic con el botón derecho en su proyecto de Visual C++ (desde Visual Studio) y seleccione Propiedades. En Configuración Properties-> C/C++ -> Generación de código

---

Documentación advierte expresamente que no utilicemos/solución NODEFAULTLIB. (ejemplo/NODEFAULTLIB: msvcrt). ¿Por qué? ¿Cómo causaría problemas? que es exactamente?

Sigue su consejo y no lo hagas.

---

Por favor, explique el último punto en la documentación para usuarios de MFC. Porque voy a usar MFC más adelante en este proyecto. Explica por qué deberíamos hacerlo? ¿Qué problemas causaría si no lo hago?

Debido a que MFC está vinculado dinámicamente al tiempo de ejecución C, utilizando bibliotecas que están enlazados estáticamente al tiempo de ejecución C hará que los errores de enlace que aparece en primer lugar en su puesto.

---

Algo más que le gustaría hablar? Me refiero a errores similares. Estoy muy interesado en Linker & sus problemas. Entonces, si hay algo similar, puede mencionarlos o algunas palabras clave al menos.

Desde mi experiencia, siempre se vincula dinámicamente con el tiempo de ejecución de C. Por lo general, le ahorra muchos dolores de cabeza como el que está experimentando en este momento.

Answer 3

Debe configurar las propiedades del proyecto para que los enlaces de compilación de depuración con la versión de depuración de DCMTK y los enlaces de compilación de la versión con la compilación de DCMTK.

Lo anterior es lo que necesita hacer. A continuación hay explicaciones de algunas otras cosas aleatorias sobre las que preguntaste.

Las versiones anteriores de Visual Studio solían tener bibliotecas de subprocesos únicos (versiones de depuración y de depuración) además de las bibliotecas multiproceso (versiones de depuración y de depuración). Para su proyecto, puede pretender que nunca existieron bibliotecas de un solo subproceso.

Si experimentas con formas aleatorias de engañar al enlazador para que se cierre y deje problemas para que los encuentren tus clientes en lugar de hacerlo tú mismo, es posible que la opción/NODEFAULTLIB lo haga. Los creadores de la biblioteca DCMTK te advierten que no hagas eso porque otras personas hicieron lo mismo en el pasado.