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

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.