La biblioteca de tiempo de ejecución no coincide y VC++ - ¡Oh, la miseria!

Question

Parece que toda mi vida adulta me ha atormentado porque el enlazador de VC++ se queja o se niega porque varias bibliotecas no están de acuerdo con qué versión de la biblioteca de Runtime usar. Nunca estoy de humor para dominar ese tema deprimente. Así que solo trato de meterme con eso hasta que funcione. Los mensajes de error nunca son útiles. Tampoco es la documentación de Microsoft sobre el tema, al menos para mí.

A veces no encuentra funciones, porque el cambio de nombre no es el esperado? A veces se niega a mezclar y combinar. Otras veces solo dice, "LINK: advertencia LNK4098: defaultlib 'LIBCMTD' entra en conflicto con el uso de otras librerías; use/NODEFAULTLIB: library" Usar/NODEFAULTLIB no funciona, pero la advertencia parece ser benigna. ¿Qué diablos es "DEFAULTLIB" de todos modos? ¿Cómo decide el vinculador? Nunca he visto una forma de especificar al enlazador qué biblioteca de tiempo de ejecución utilizar, solo cómo decirle al compilador para qué biblioteca crear llamadas de función.

Existen programas de "walker de dependencias" que pueden inspeccionar archivos de objetos para ver de qué DLL dependen. Acabo de ejecutar uno en un proyecto que estoy tratando de construir, y es un verdadero desastre. Hay sistemas .libs y .dll que desean versiones en tiempo de ejecución conflictivas. Por ejemplo, COMCTL32.DLL quiere MSVCRT.DLL, pero estoy enlazando con MSVCRTD.DLL. Estoy buscando para ver si hay un COMCTL32D.DLL, incluso mientras escribo.

Así que supongo que lo que estoy pidiendo es un tutorial sobre cómo resolver esas cosas. ¿Qué haces y cómo lo haces?

Esto es lo que creo que sé. Por favor corrígeme si algo de esto está mal.

1. Los parámetros son Debug/Release, Multi-threaded/Single-threaded, y static/DLL. Solo seis de las ocho combinaciones posibles están cubiertas. No hay DLL de subproceso único, ya sea Debug o Release.

2. La configuración solo afecta a qué biblioteca de tiempo de ejecución se vincula (y la convención de llamadas para vincularse con ella). Por ejemplo, no tiene que utilizar un tiempo de ejecución basado en DLL si está compilando un archivo DLL, ni tiene que utilizar una versión de depuración del tiempo de ejecución al compilar la versión de depuración de un programa, aunque parece ser útil cuando solo pasando las llamadas al sistema.

Pregunta adicional: ¿Cómo puede alguien o cualquier empresa crear un desastre?

Answer 1

Sus puntos (1) y (2) me parecen correctos. Otra cosa a tener en cuenta con (2) es que la vinculación en la depuración CRT también le da acceso a cosas como la verificación de pila mejorada, los iteradores marcados y otras verificaciones de cordura variadas. Sin embargo, no puede redistribuir el CRT de depuración con su aplicación; debe enviar únicamente con la versión de lanzamiento. No solo es requerido por la licencia de VC, sino que probablemente no desee enviar binarios de depuración de todos modos.

No existe tal cosa como COMCTL32D.DLL. Los archivos DLL que forman parte de Windows deben cargar el CRT con el que estaban vinculados cuando se compiló Windows, esto se incluye con el sistema operativo como MSVCRT.DLL. Este Windows CRT es completamente independiente del CRT de Visual C++ que se carga con los módulos que componen su programa (MSVCRT.DLL es el que se envía con Windows. El VC CRT incluirá un número de versión, por ejemplo MSVCRT80.DLL). Solo los archivos EXE y DLL que componen su programa se ven afectados por la configuración de depuración/liberación de subprocesos/subprocesamiento único.

La mejor práctica aquí IMO es elegir una configuración para su CRT y estandarizarla para cada binario que envíe. Yo personalmente usaría el tiempo de ejecución DLL multiproceso. Esto se debe a que Microsoft puede (y lo hace) emitir actualizaciones de seguridad y correcciones de errores a la CRT que pueden enviarse a través de Windows Update.