Tengo un problema molesto que de alguna manera podría eludir, pero por otro lado preferiría estar en la parte superior y entender qué es exactamente pasando, ya que parece que esto realmente está aquí para quedarse.Agregar Boost hace que la compilación de depuración dependa de las DLL de tiempo de ejecución de MSVC "no D"
Aquí está la historia: Tengo una aplicación OpenGL simple que funciona bien: nunca un problema importante en la compilación, vinculación o ejecución. Ahora decidí tratar de mover algunos de los cálculos más intensivos en un hilo de trabajo, para posiblemente hacer que la GUI sea aún más receptiva, usando Boost.Thread, por supuesto.
En resumen, si añado el siguiente fragmento en el comienzo de mi archivo .cpp:
#include <boost/thread/thread.hpp>
void dummyThreadFun() { while (1); }
boost::thread p(dummyThreadFun);
, entonces comienza a recibir "Esta aplicación no pudo iniciar porque no se encontró msvcp90.dll" cuando tratando de lanzar la compilación Debug (El modo de liberación funciona bien)
Ahora, mirando el archivo ejecutable usando Dependency Walker, que tampoco encuentra esta DLL (lo que se espera supongo), pude ver que lo estamos buscando para poder llamar a las siguientes funciones:
[email protected][email protected]@[email protected]@SAKXZ
[email protected][email protected][email protected]@@SA_JXZ
[email protected][email protected]@[email protected]@SAKXZ
[email protected][email protected][email protected]@@SA_JXZ
a continuación, traté de convertir todas las instancias de min y max utilizar macros en su lugar, pero probablemente no podría encontrar todas las referencias a ellos, ya que esto no ayuda. (Estoy usando algunas bibliotecas externas para las cuales no tengo el código fuente disponible. Pero incluso si pudiera hacer esto, no creo que sea la manera correcta en realidad.)
Entonces, mis preguntas - I Supongo que son:
- ¿Por qué buscamos una DLL sin errores aunque trabajemos con la compilación de depuración?
- ¿Cuál es la forma correcta de solucionar el problema? ¿O incluso uno rápido y sucio?
Tuve esto primero en una instalación bastante generalizada de Visual Studio 2008. Luego probé a instalar Feature Pack y SP1, pero tampoco me ayudaron. Por supuesto, también intenté reconstruir varias veces.
Estoy utilizando binarios precompilados para Boost (v1.36.0). Esta no es la primera vez que uso Boost en este proyecto, pero puede ser la primera vez que uso una parte que se basa en una fuente separada.
Desactivar el enlace incremental no ayuda. El hecho de que el programa es OpenGL tampoco parece ser relevante. Obtuve un problema similar al agregar las mismas tres líneas de código en un programa de consola simple (pero allí estaba quejándose de MSVCR90.dll y _mkdir, y cuando reemplazado este último con boost::create_directory, el problema desapareció !!). Y en realidad es solo eliminar o agregar esas tres líneas lo que hace que el programa se ejecute bien o no se ejecute en absoluto, respectivamente.
No puedo decir que entiendo Side-by-Side (ni siquiera sé si esto está relacionado, pero eso es lo que supongo por ahora), y para ser sincero, tampoco estoy muy interesado, siempre y cuando como puedo construir, depurar e implementar mi aplicación ...
Edición 1: Al tratar de construir un ejemplo reducidos al mínimo, que reproduce todos modos el problema, he descubierto que el problema tiene que ver con the Spread Toolkit, cuyo uso es un factor común a todos mi programas que tienen este problema (Sin embargo, nunca tuve esto antes de comenzar a vincular las cosas de Boost).
Ahora he encontrado un programa mínimo que me permite reproducir el problema. Consta de dos unidades de compilación, A.cpp y B.cpp.
a.cpp:
#include "sp.h"
int main(int argc, char* argv[])
{
mailbox mbox = -1;
SP_join(mbox, "foo");
return 0;
}
B.cpp:
#include <boost/filesystem.hpp>
Algunas observaciones:
- Si comento hacia fuera de la línea de
SP_joina.cpp, el problema va lejos. - Si comento la línea individual de B.cpp, el problema desaparece.
- Si muevo o copio la línea individual de B.cpp al principio o al final de A.cpp, el problema desaparece.
(En los escenarios 2 y 3, el programa se bloquea cuando se llama a SP_join, pero eso es sólo porque el buzón no es válida ... esto no tiene nada que ver con el tema en cuestión.)
Además , La biblioteca principal de Spread está vinculada, y eso seguramente forma parte de la respuesta a mi pregunta n. ° 1, ya que no hay una compilación de depuración de esa lib en mi sistema.
Actualmente, estoy tratando de encontrar algo que permita reproducir el problema en otro entorno. (A pesar de que voy a ser muy sorprendido si en realidad se puede repetir fuera de mi local ...)
Edición 2: Ok, así here ahora tenemos un paquete con el que yo era capaz de reproducir el problema en una instalación casi vanilla de WinXP32 + VS2008 + Boost 1.36.0 (todavía pre-built binaries from BoostPro Computing).
El culpable es sin duda el Spread lib, mi versión de la que de alguna manera requiere una versión bastante arcaica de STLPort para MSVC 6! Sin embargo, todavía encuentro los síntomas relativamente divertidos. Además, sería bueno saber si realmente puedes reproducir el problema, incluidos los escenarios 1-3 anteriores. El paquete es bastante pequeño y debe contener todas las piezas necesarias.
Como resultado, el problema en realidad no tenía nada que ver con Boost. Lea específicamente, ya que este ejemplo ahora usa la biblioteca Boost Filesystem. Además, ahora se queja de MSVCR90.dll, no de P como anteriormente.
Tengo definido _DEBUG ... Los binarios preconstruidos son de BoostPro Computing (http://www.boostpro.com/products/free), y estoy dejando que el mecanismo de enlace automático haga su trabajo. – Reunanen
Eso es más extraño. Estoy perplejo en este momento. ¿Puedes reproducir el problema en un programa completo que puedes publicar? –
Es difícil de decir en este momento, pero tendré que considerar esa posibilidad. – Reunanen