For a MSVC9 Win32 project following options are shown under Configuration Properties -> C/C++ -> Code Geberation -> Runtime Library:
/MT, /MTd, /MD, /MDd
is it correct that for a DLL /MTd should be used and for static lib /MDd?
Thanks.
There are two issues that are at play here.
First, you need to choose if you want the Debug version of the CRT or the Release version. The debug versions have special checks and code paths designed to help you catch bugs while writing an application. You should not use them for the final release version of an application because they can slow down its execution, and because they are not freely redistributable.
Then, you need to decide if you want to statically link the run-time to your application, or if you want to use it dynamically from a DLL. Static linking allows you to create a standalone EXE file with no dependencies on any DLL files; it effectively compiles the run-time code into your application's binary. This can make deployment easier, but it comes at the cost of not being able to take advantage of security and other updates that are made to the run-time DLLs. You'll have to recompile your application in order to take advantage of the new run-time updates. Dynamic linking is the typical (and recommended) path for Windows applications. It means that your application will require the appropriate versions of the CRT DLLs to be present in order for it to run, but it allows the run-time libraries to be easily updated and means that multiple programs can share the same code, reducing their size on disk.
So, /MD means dynamically-linked and /MT means statically-linked. The lower-case d after each option indicates that the debug version of the run-time libraries is used.
/MD = dynamically-linked to release (redistributable) version of CRT
/MDd = dynamically-linked to debug (non-redistributable) version of CRT
/MT = statically-linked to release (redistributable) version of CRT
/MTd = statically-linked to debug (non-redistributable) version of CRT
More information is available on MSDN.
Related
I'm reading about /MT and /MD, but I'm a little confused about it
HEAR is something I don't completely understand :
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
what does it mean?
If you link with /MD or /MDd your program is going to need the CRT dlls in order to run. typically they are called something like msvcp100.dll for the C++ runtime and msvcr100.dll for the C runtime. If you are deploying your application using an installer, you can add a package with these to your installer so the dlls are going to be there when someone runs the application. If on the other hand you are going to deploy your application just as a single stand alone exe, your users are going to need a copy of these dlls. The latest versions of these dlls usually come with windows itself (not the debug ones) but if your user is running an older version of windows it may not have the needed dlls.
Linking your application to the static version of the CRT saves this whole headache for the price that the exe is slightly bigger (since it contains the CRT in it)
If you do use /MT (Static CRT) you have to make sure that everything else that you statically link with uses /MT as well. otherwise you'll end up with an executable where part of the code uses the static CRT and part is still depends on the CRT DLL. Other than defeating the basic purpose not needing the CRT DLL, this can also cause other problems.
To make sure what DLLs your exe depends on you can use the dependency walker.
Does it link against the runtime library when i build my static lib? Does it "put" the code from runtime lib into my lib?
Or is it just information for linker, so that when it links final exe(dll) it knows what version of runtime library to use for this particular static library?
Do i need to use the same version of runtime library in all my static libs and dlls?
Do i need to use the same type (/MT /MTd /MDd ...) in all my static libs and dlls?
And one more short question, is it usual that static windows libraries are twice the size of linux static libraries?
Or is it just information for linker, so that when it links final
exe(dll) it knows what version of runtime library to use for this
particular static library?
Yes.
Do i need to use the same version of runtime library in all my static
libs and dlls?
I strongly strongly advise it. You will get a mess of linker errors if you don't.
Do i need to use the same type (/MT /MTd /MDd ...) in all my static
libs and dlls?
Yes.
If you are releasing a DLL to be consumed by a 3rd-party, you may want to provide them with YourLibraryD.dll which uses the /MTd flag, and a YourLibrary.dll which uses /MT. Have different solution configurations for each. Nobody uses the single-threaded versions any longer, because the performance penalty is mostly irrelevant now and not worth the risk.
EDIT: Even if you aren't releasing to a 3rd party, you still want to make sure you link to the right DLL when in debug -vs- release mode. This is because when you build YourApp.exe in Debug, which uses /MTd, you will want it to link to YourLibraryD.dll. When you build YourApp.exe in Release, which uses /MT, you will want it to link to YourLibrary.dll in release mode. You could keep the DLL name the same and use the directory to disambiguate: so then you link to bin\debug\YourLibrary.dll in debug mode, and bin\release\YourLibrary.dll in release mode. Sorry if this is beyond your question, it is just good to know when you first switch build configurations and suddenly you start getting linker errors.
I build /mt (run-time library:multi-threaded) and /md (run-time library:multi-threaded-dll) versions of my C++ DLL with visual studio 2008.
Applications which link to the /md build runs fine,
but applications which link to the /mt build crash.
Interestingly applications which link to the static version of the /mt build work fine.
Does it make sense to build a DLL with /mt and use it with an application which is also built with /mt?
How can I trace the reason for this sort of crash?
Regards,
Paul
It depends on your API. If you build your executables with the non-DLL version of the run time libraries then each DLL and EXE gets it's own copy of the static data of the run time libraries. The most obvious effect is that you can't allocate something dynamically from one module (DLL or EXE) and expect to safely free it in another module. There going to be other less common issues, for example if you srand in one module, don't expect it to affect calls to rand across the application.
It's generally safest in an executable that links against other user DLLs to compile them all against the DLL version of the run time libraries. You might want to use the static versions of the run time libraries if you were building a statically linked executable using static libraries, perhaps for ease of packaging and distribution but I don't see much benefit in a hybrid configuration given the potential issues.
In the static release of my application, I do not want the user to need the msvcrt runtime. My application depends on another library that I compile myself. Should this library use multithreaded or multithreaded DLL when compiling it? The library is static compiled.
Thanks
VC++'s license agreement prohibits the distribution of debug builds on any computer that doesn't already have VC++ installed, so your only option is to use /MTd or /MDd for debug builds while developing the application and /MT for the release build meant for distribution.
You should use DLL CRTs wherever possible, you can end up with trouble if you start linking multiple copies statically. If you know for a fact that you're compiling the final product, then you could link statically.
In Visual Studio, there's the compile flags /MD and /MT which let you choose which kind of C runtime library you want.
I understand the difference in implementation, but I'm still not sure which one to use. What are the pros/cons?
One advantage to /MD that I've heard, is that this allows someone to update the runtime, (like maybe patch a security problem) and my app will benefit from this update. Although to me, this almost seems like a non-feature: I don't want people changing my runtime without allowing me to test against the new version!
Some things I am curious about:
How would this affect build times? (presumably /MT is a little slower?)
What are the other implications?
Which one do most people use?
By dynamically linking with /MD,
you are exposed to system updates (for good or ill),
your executable can be smaller (since it doesn't have the library embedded in it), and
I believe that at very least the code segment of a DLL is shared amongst all processes that are actively using it (reducing the total amount of RAM consumed).
I've also found that in practice, when working with statically-linked 3rd-party binary-only libraries that have been built with different runtime options, /MT in the main application tends to cause conflicts much more often than /MD (because you'll run into trouble if the C runtime is statically-linked multiple times, especially if they are different versions).
If you are using DLLs then you should go for the dynamically linked CRT (/MD).
If you use the dynamic CRT for your .exe and all .dlls then they will all share a single implementation of the CRT - which means they will all share a single CRT heap and memory allocated in one .exe/.dll can be freed in another.
If you use the static CRT for your .exe and all .dlls then they'll all get a seperate copy of the CRT - which means they'll all use their own CRT heap so memory must be freed in the same module in which it was allocated. You'll also suffer from code bloat (multiple copies of the CRT) and excess runtime overhead (each heap allocates memory from the OS to keep track of its state, and the overhead can be noticeable).
I believe the default for projects built through Visual Studio is /MD.
If you use /MT, your executable won't depend on a DLL being present on the target system. If you're wrapping this in an installer, it probably won't be an issue and you can go either way.
I use /MT myself, so that I can ignore the whole DLL mess.
P.S. As Mr. Fooz points out, it's vital to be consistent. If you're linking with other libraries, you need to use the same option they do. If you're using a third party DLL, it's almost certain that you'll need to use the DLL version of the runtime library.
I prefer to link statically with /MT.
Even though you do get a smaller executable with /MD, you still have to ship a bunch of DLLs to make sure the user gets the right version for running your program. And in the end your installer is going to be BIGGER than when linking with /MT.
What's even worse, if you choose to put your runtime libraries in the windows directory, sooner or later the user is going to install a new application with different libraries and, with any bad luck, break your application.
The problem you will run into with /MD is that the target version of the CRT may not be on your users machine (especially if you're using the latest version of Visual Studio and the user has an older operating system).
In that case you have to figure out how to get the right version onto their machine.
from http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.71).aspx:
/MT Defines _MT so that multithread-specific versions of the run-time routines are selected from the standard header (.h) files. This option also causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols. Either /MT or /MD (or their debug equivalents /MTd or /MDd) is required to create multithreaded programs.
/MD Defines _MT and _DLL so that both multithread- and DLL-specific versions of the run-time routines are selected from the standard .h files. This option also causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR71.DLL, which must be available at run time to applications linked with MSVCRT.lib.
When /MD is used with _STATIC_CPPLIB defined (/D_STATIC_CPPLIB) it will cause the application to link with the static multithread Standard C++ Library (libcpmt.lib) instead of the dynamic version (msvcprt.lib) while still dynamically linking to the main CRT via msvcrt.lib.
So if I am interpreting it correctly then /MT links statically and /MD links dynamically.
If you are building executable that uses other dlls or libs than /MD option is preferred because that way all the components will be sharing same library. Of course this option should match for all the modules involved i.e dll/lib/exe.
If your executable doesn't uses any lib or dll than its anyone's call. The difference is not too much now because the sharing aspect is not into play.
So maybe you can start the application with /MT since there is no compelling reason otherwise but when its time to add a lib or dll, you can change it to /MD with that of the lib/dll which is easy.