Why is /clr incompatible with /mt and /mtd in Visual Studio?

Question

can anybody please explain for me how and why /clr is incompatible with /mtd ? What is the alternative for this? What happens internally if I use /md or /mdd ?

As far as I know we don't combinedly use /clr and /mtd. Can someone explain if there is a way to do this? And please explain me how and why /clr is incompatible with /mt and /mtd in Visual Studio?

Iapetus

Why do you want both /clr & /mtd? If you tell us what you are trying to achieve we might be able to help you to do that. – Chasitychasm

.. Could be he's just curious :) – Corabella

Answer 1

I expect the clue is given here:

If you are using the /clr compiler switch, your code will be linked with an import library, msvcmrt.lib. The import library references a new library, msvcm80.dll, which provides a proxy between your managed code and the native CRT. You cannot use the statically linked CRT ( /MT or /MTd options) with /clr. Use the dynamically-linked libraries (/MD or /MDd) instead.

The /clr flag causes your code to reference a new dll msvcm80.dll - this acts as a proxy between your managed code and the CRT. It's difficult to say exactly what this proxy does, but I guess it acts as an interface for allocations on the managed heap, garbage collection, managed threads and that kind of thing. If you link the static versions of the CRT, then the proxy would not be able to intercept your calls to the runtime libraries.

Colewort

great answer, can I use C++/CLI with /mt flag somehow ? – Stipple

@Stipple Why would you want it? The library you are linking to is thread safe and there is no reason for static linking once you request CLR to be present anyway, therefore I cannot see any drawbacks. – Virago

I think that the main reason for being able to link with the static CRT libraries is to NOT have to install the redistributables on the target machines. – Unkempt