c++ - microsoft - MSVCP110D.dll y Visual Studio 2013

microsoft visual c++ 2014 redistributable package(x64)

Question

Estoy intentando ejecutar un programa que compilé en Visual Studio 2013. Sin embargo, recibo el error

The program can''t start because MSVCP110D.dll is missing from
your computer. Try reinstalling the program to fix this problem.

Este no es un error muy útil. Sin embargo, después de buscar en Google, descubrí que (al parecer) intenta cargar una biblioteca de c++ estándar de forma dinámica, y que para evitar esto necesito especificar la opción /MT lugar de la opción /MD . Esto me deja con una cantidad de preguntas:

1. ¿Qué está haciendo exactamente eso?
2. ¿Cuáles son los beneficios de /MD en comparación con /MT ? Quiero decir, debe haber una razón por la cual son las opciones predeterminadas ...
3. ¿Cómo conseguiré el .dll buscado y conseguiré que Visual Studio lo use? Lo descargué, pero sinceramente no sé exactamente cómo usarlo.
4. Lo que es más importante, ¿cómo puedo evitar que ese error desaparezca y mi programa se ejecute?

Alguna información adicional: estoy compilando en modo de Release usando una compilación x64 .

Answer 1

El problema es que está mezclando diferentes versiones de Visual Studio usando Qt que se compiló usando un compilador diferente. Recuerde que cada versión de Visual Studio tendrá su propio tiempo de ejecución / CRT. Los dlls de Qt compilados con Visual Studio 2012 y dependerán del tiempo de ejecución de Visual Studio 2012. No usarán el tiempo de ejecución 2013.

La solución a este problema es recompilar todo el código y las bibliotecas / DLL dependientes con el mismo compilador.

Advertencia: Algunos usuarios intentarán simplemente instalar el tiempo de ejecución dinámico (o recompilar bibliotecas dependientes con CRT estático) de la otra versión de Visual Studio; sin embargo, esto no es una solución a este problema, principalmente porque cada tiempo de ejecución tiene su propio montón independiente. Tener montones separados puede provocar colisiones aleatorias causadas por asignar memoria en un montón y luego tratar de liberarla en un montón diferente. Dado que los montones no comparten información sobre asignaciones o desasignaciones, esto conduce a tener acumulaciones corruptas. Según mi experiencia, el problema no siempre causa un bloqueo instantáneo. El bloqueo puede o no ocurrir en la siguiente asignación del montón corrupto, por lo que la eliminación de errores de esta situación puede ser muy frustrante.