Foros

Hola amiguitos

Al final he caido y tras pasar una apasionante tarde-noche de sabado instalando Mac y Windows, he instalado Visual C++ 2008 Express Edition.

He conseguido compilar mi codigo pero como la ultima vez que use Visual C++ aun estaba en el VC6, pues veo cosas “raras”…

Lo mas raro que he encontrado es que la primera vez que he compilado, he tratado de ejecutar el programa y me ha dado el fastuoso error “this application has failed to start because msvcp90d.dll was not found”.
Le he cambiado en Configuration Properties > C/C++ > Code Generation > Runtime Library a “MultiThreaded DLL /MD”.
Asi ya no me pide la dll de debug.

Pero me da mal rollo porque me da la impresion de que cuando lo ejecuten en el ordenador de la compo, va a petar porque no tendra una de esas famosas DLL’s.

Asi que la pregunta es: Hay alguna forma de que el codigo funcione “tal cual”, sin andar anyadiendo DLL’s al directorio de la demo?

Compilando en estatico todo lo que puedas, eso si, procura estar sentada antes de mirar el tamaño del exe resultante

Cierto, si no es para una 64ks el linking estático te va bien como dice winden, en caso contrario /NODEFAULTLIB

Más información en msdn

Suerte.

Me lo miro, thanks

Por cierto, estas cosas… pasaban tambien en Visual C 6 pero estaban “escondidas”, o es algun cambio a partir de VS2005? Es que me suena que cuando Corsario compilo mi demo en la breakpoint 2006 me dijo que “noseque” de la stdlib, o algo asi era (ni que me acuerde a estas alturas…).

Por cierto, kneda, usas la msdn en espanyol?! Me cuesta mas entenderlo que si estuviera en ingles

Que va, yo no uso la msdn yo pregunto directamente a los que saben…

Y sí, tienes razón, la traducción de la msdn al español parece que la hayan pasado por uno de estes fantabulosos viejos traductores automáticos … recuerdo uno que se llamaba powertranslator, y la verdad si que era power, pero cuando le pedías traducir una palabra, si ya le metías más de uno se desinflaba

tienes que cambiar en Configuration Properties > C/C++ > Code Generation > Runtime Library. Cambia de “MultiThreaded DLL” a “MultiThreaded” y ya no te pedira la DLL Cuando compiles en debug puedes dejar “Multithreaded Debug” y no te pedira ninguna DLL tampoco.

Bueno, la msvcp90d.dll es la runtime del modo debug.
Yo tambien tuve algun problema con eso.
Tal como dicen, poniendo Multithreaded ya no deberia pedir DLLs.

De todos modos, tal como me dijo Shash, lo mejor es que una vez lo vayas a sacar de tu ordenador (para pasarlo al de la compo) lo compiles en modo Release y te olvides de la msvcp90d.dll
Esto es debido (si no me equivoco) a que microsoft no distribuye la dll de debug con el “distributable runtime” solo con el visual studio entero

a vers, aquí hay una confusión. La dependencia de tu ejecutable con dlls externas no tiene que ver con debug o no debug, sino con el “DLL” o no “DLL”.

• Mutithread DLL -> pedira una dll que casi nadie tiene (msvcp90.dll)
• Debug Mutithread DLL -> pedira una dll que casi nadie tiene (msvcp90d.dll)
• Mutithread -> NO PEDIRA NINGUNA DLL
• Debug Mutithread -> NO PEDIRA NINGUNA DLL, aunque sea debug

compila en debug o relase, como más te guste, sólo asegúrate de que no tengas el “DLL”. Aunque tampoco se me ocurre por qué querrías distribuir algo en debug.

Y para comentar más, en VC6.0 también pasaban estas cosas, pero el runtime de VC6.0 viene con todos los equipos desde Windows XP, no siendo así para los posteriores runtimes de VS.

Pues lo cierto es que cada vez que cambio a Multithread (MT) me sale este churrito de errores:

1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _isspace already defined in LIBCMT.lib(_ctype.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _fprintf already defined in LIBCMT.lib(fprintf.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: ___iob_func already defined in LIBCMT.lib(_file.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _fopen already defined in LIBCMT.lib(fopen.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _fclose already defined in LIBCMT.lib(fclose.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _setvbuf already defined in LIBCMT.lib(setvbuf.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _exit already defined in LIBCMT.lib(crt0dat.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _strrchr already defined in LIBCMT.lib(strrchr.obj)
1>msvcrt.lib(MSVCR90.dll) : error LNK2005: _atoi already defined in LIBCMT.lib(atox.obj)
1>LIBCMT.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

Y si pongo /NODEFAULTLIB:msvcrt.lib en las additional linker options, me salen nuevos errores:

2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _isspace imported in function _ParseCommandLine
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _fprintf imported in function _ShowError
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol ___iob_func imported in function _ShowError
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _fopen imported in function _cleanup_output
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _fclose imported in function _cleanup_output
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _setvbuf imported in function _redirect_output
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _exit imported in function _main
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _strrchr imported in function _main
2>SDLmain.lib(SDL_win32_main.obj) : warning LNK4217: locally defined symbol _atoi imported in function _WinMain@16
2>SDLmain.lib(SDL_win32_main.obj) : error LNK2019: unresolved external symbol __imp__remove referenced in function _cleanup_output

… entre otros, supongo que porque SDL asume que va a encontrarse ciertos simbolos que luego no estan 8-)

La verdad es que es una cochinada, pero me parece que al final compilare con MultiThread + DLL y dejare la DLL en el directorio de la demo