Why are there so many libraries in MSVC and why do I have to recompile the code again

Question

In every platform there are various versions of a given library: multi-threaded, debug, dynamic, etc..

Correct me if I am wrong here, but in Linux an object can link to any version of a library just fine, regardless of how its compiled. For example, there is no need to use any special flags at compile time to specify whether the link will eventually be to a dynamic or a static version of the run-time libraries (clarification: I am not talking about creating dynamic/static libraries, I am talking about linking to them - so -fPIC doesn't apply). Same goes for debug or optimized version of libraries.

Why in MSVC (Windows in general with other compilers. true?) I need to recompile the code every time in order to link to different versions of libraries? I am talking the /MD, /MT, /MTd, /MDd, etc flags. Is the code actually using different system headers each time. If so, why?

I would really appreciate any pointers to solid documentation that discusses these library matters in Windows for a C/C++ programmer..

thanks!

Answer 1

All of the options use the same header files, however they all imply different #define which affect the header files. So they need to be recompiled.

The switches also link to the appropriate library, but the recompile is not because of the linking.

See here for a list of what is defined when you use each.

Answer 2

These using these compiler options have two effects. The automatically #define a macro that may be used by header files (and your own code) to do different things. This effects only a small part of the C runtime, and you can check the headers to see if it's happening in your case.

The other thing is that the C++ compiler embeds a comment in your object file that tells the linker to automatically include a particular flavor of the MSVC runtime, whether you specify that library at link time or not.

This is convenient for small programs, where you simply type at a command prompt cl myprogram.cpp to compile and link, producing myprogram.exe.

You can defeat automatic linking of the commented-in flavor of the c-runtime by passing /nodefaultlib to the linker. And then specify a different flavor of the c-runtime instead. This will work if you are careful not to depend on the #defines for _MT and _DLL (keep in mind that the standard C headers might be looking at these also).

I don't recommend this, but if you have a reason to need to do this, it can be made to work in most cases.

If you want to know what parts of the C header files behave differently, you should just search for _MT and _DLL in the headers and see.

Answer 3

The compiler setting does very little other than simple change some macro definitions. Its microsoft's c-runtime header files that change their behaviour based on the runtime selected.

First, the header files use a # pragma directive to embed in the object file a directive specifying which .lib file to include, choosing one of: msvcrt.lib, msvcrtd.lib, libcmt.lib and mibcmtd.lib

The directives look like this

#ifdef <release dll runtime>
#pragma comment(lib,"msvcrt.lib")
#endif

Next, it also modifies a macro definition used on all c-rt functions that adds the __declspec(dllimport) directive if a dll runtime was selected. the effect of this directive is to change the imported symbol from, say, '_strcmp' to '__imp__strcmp'.

The dll import libraries (msvcrt.lib and msvcrtd.lib) export their symbols (to the linker) as __imp_<function name>, which means that, in the Visual C++ world, once you have compiled code to link against the dll runtimes you cannot change your mind - they will NOT link against a static runtime. Of course, the reverse is not the case - dll import libraries actually export their public symbols both ways: with and without the __imp_ prefix. Which means that code built against a static runtime CAN be later co-erced into linking with the dll or static runtimes.

If you are building a static library for other consumers, you should ensure that your compiler settings include:

1. One of the static library settings, so that consumers of your .lib can choose themselves which c-runtime to use, and
2. Set the 'Omit Default Library Name' (/Zl)flag. This tells the compiler to ignore the #pragma comment(lib,... directives, so the obj files and resulting lib does NOT have any kind of implicit runtime dependency. If you don't do this, users of your lib who choose a different runtime setting will see confusing messages about duplicate symbols in libc.lib and msvcrt.lib which they will have to bypass by using the ignore default libraries flag.