// test.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "SDL/SDL.h"
int main( int argc, char* args[] )
{
//Start SDL
SDL_Init( SDL_INIT_EVERYTHING );
//Quit SDL
SDL_Quit();
return 0;
}
[fixed] warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs
Author
Can anybody tell me what this means? This is not my usual compiler, but I need to port my code. What further information do I need to give you guys to fix this problem? I can tell you that I'm linking SDL.lib and SDLmain.lib, and the the application is a console project.
Here is the only code I have so far:
Thanks
Go to your project properties->C/C++->Code Generation->Runtime Library and change it to Multi-threaded DLL.
Author
Quote:Original post by SiCrane
Are you asking about a debug build or a the debug version of the runtime library?
Hmm, I'm a bit puzzled. It builds by default as a debug DLL, rather than an executable. and, if I change it to an executable, it won't compile.
The options are:
Multi-threaded (/MT)
Multi-threaded Debug (/MTd)
Multi-threaded DLL (/MD)
Multi-threaded Debug DLL (/MDd)
Currently I have it set to "/MD".
(I'm googling my various error messages and finding solutions. I've been reading This)
I just need to know the difference. My IDE is VS Express 2008, and its running VC++9. Im having a hard time finding VS2008 specific information. For now, I'll stick with '/MD'
That doesn't control whether or not your project is built as a DLL or executable, that controls which version of the runtime library your project is built with, hence why it's labeled "Runtime Library". What kind of module your project is built as is controlled by a linker option.
Multi-threaded (/MT): The CRT (C RunTime library) version you link to is thread safe, and is a static library. That results in your EXE being larger, and means you don't benefit from any security updates to the CRT (via Windows Update) but means you don't need to ship the CRT DLL with your app; or more correctly provide the VC9 Redustributable package.
Multi-threaded Debug (/MTd): Same as above, the it's the debug version. When you call new or malloc, the memory you get back will be filled with some recognisable pattern (0xcc I think), when you call delete or free, the memory gets shat on so you don't accidently use it again. The debug runtimes are slower, and end users don't have them (They only exist if you have the platform SDK installed), but they make tracking bugs down a bit easier.
Multi-threaded DLL (/MD)
Multi-threaded Debug DLL (/MDd): As above, but the CRT is in a DLL (msvcrt80.dll for VC2005, or various other versions for other VC versions). The end user needs to have the CRT installed, or your app will give a lovely "One or more DLLs were not found" or something, when trying to load the EXE. Generally that's not too much of a concern though; other apps will usually provide the DLLs as part of their install procedure.
The two DLL versions are the usual methods of linking to the CRT. As I said, the DLLs are usually present on the users system. If you want to be professional, you should install them as part of your installer, but they're probably already present, and if they're not you can always include the DLLs with your EXE (That might actually be against the EULA, anyone know?)
EDIT: You used to be able to get non-multi-threaded versions of the CRT (You did in VC6, I don't know about VC2003). They're probably slightly faster, but also a lot less secure - they don't cope with new or delete or any CRT functions being called from different threads, and it's generally a bad idea.
Multi-threaded Debug (/MTd): Same as above, the it's the debug version. When you call new or malloc, the memory you get back will be filled with some recognisable pattern (0xcc I think), when you call delete or free, the memory gets shat on so you don't accidently use it again. The debug runtimes are slower, and end users don't have them (They only exist if you have the platform SDK installed), but they make tracking bugs down a bit easier.
Multi-threaded DLL (/MD)
Multi-threaded Debug DLL (/MDd): As above, but the CRT is in a DLL (msvcrt80.dll for VC2005, or various other versions for other VC versions). The end user needs to have the CRT installed, or your app will give a lovely "One or more DLLs were not found" or something, when trying to load the EXE. Generally that's not too much of a concern though; other apps will usually provide the DLLs as part of their install procedure.
The two DLL versions are the usual methods of linking to the CRT. As I said, the DLLs are usually present on the users system. If you want to be professional, you should install them as part of your installer, but they're probably already present, and if they're not you can always include the DLLs with your EXE (That might actually be against the EULA, anyone know?)
EDIT: You used to be able to get non-multi-threaded versions of the CRT (You did in VC6, I don't know about VC2003). They're probably slightly faster, but also a lot less secure - they don't cope with new or delete or any CRT functions being called from different threads, and it's generally a bad idea.
Author
Quote:Original post by Evil Steve
Multi-threaded (/MT): The CRT (C RunTime library) version you link to is thread safe, and is a static library. That results in your EXE being larger, and means you don't benefit from any security updates to the CRT (via Windows Update) but means you don't need to ship the CRT DLL with your app; or more correctly provide the VC9 Redustributable package.
Multi-threaded Debug (/MTd): Same as above, the it's the debug version. When you call new or malloc, the memory you get back will be filled with some recognisable pattern (0xcc I think), when you call delete or free, the memory gets shat on so you don't accidently use it again. The debug runtimes are slower, and end users don't have them (They only exist if you have the platform SDK installed), but they make tracking bugs down a bit easier.
Multi-threaded DLL (/MD)
Multi-threaded Debug DLL (/MDd): As above, but the CRT is in a DLL (msvcrt80.dll for VC2005, or various other versions for other VC versions). The end user needs to have the CRT installed, or your app will give a lovely "One or more DLLs were not found" or something, when trying to load the EXE. Generally that's not too much of a concern though; other apps will usually provide the DLLs as part of their install procedure.
The two DLL versions are the usual methods of linking to the CRT. As I said, the DLLs are usually present on the users system. If you want to be professional, you should install them as part of your installer, but they're probably already present, and if they're not you can always include the DLLs with your EXE (That might actually be against the EULA, anyone know?)
EDIT: You used to be able to get non-multi-threaded versions of the CRT (You did in VC6, I don't know about VC2003). They're probably slightly faster, but also a lot less secure - they don't cope with new or delete or any CRT functions being called from different threads, and it's generally a bad idea.
Right, I've been programming Unix for too long, forgot how windows software works. Thanks for the heads up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
