Linking a Common Language Runtime (/clr) .dll to static libraries statically linked to the C/C++ Runtime Library

Question

I have a WPF app I'm compiling in Visual Studio 2010 that uses a CLR .dll to interact with some unmanaged C/C++ code. The idea is that WPF references the CLR .dll which in turn references the unmanaged code. Unfortunately, I'm running into terrible linking issues because the unmanaged C/C++ code and related libraries all link statically to the C/C++ runtime, but if I try to use that code generation method on the CLR .dll, it throws an error because the /clr option and statically linking to the CRT are incompatible. I need to somehow glue these things together.

My thought was to try to create an additional .dll that just contained all of the unmanaged code in a single package (also linked statically to the CRT), then link that to the CLR .dll, which in turn links into the app (blech!). I tried to make such a .dll, but the problem is that (maybe obviously?) it didn't pull in any of the symbols from the static .lib files because it didn't need any of them. I tried forcing symbol references (/OPT:NOREF), but that didn't seem to do anything. It's just an empty .dll that "links" to the libs but isn't actually doing anything. So a big fail on that idea.

Am I approaching this whole thing all wrong?

I don't have source code for some of the unmanaged libraries, so I can't recompile them to link dynamically to the CRT. These linking problems are getting really frustrating!

Thanks for any suggestions!

UPDATE: I guess this is tantamount to trying to mix /MT and /MD modules together, which, according to this , is not possible. How is it that you're supposed to link projects in which you don't have control over third party libraries? You just hope that they've all chosen to use the same runtime library linking method?! Seems like a horrible idea...

Answer 1

The solution appears to be that you should not attempt to link /MT and /MD -compiled libraries together. I'm a bit surprised by it, because there are instances where you may not have control over the libraries you have to link to. And if you're trying to link into a CLR project, you'd better hope those libraries were compiled with /MD , or you're in trouble! In my case, I was able to solve it by recompiling some external libraries using /MD. There was one in particular I didn't have access to code for, and its DEFAULTLIB was a statically linked C-runtime ( libcmt.lib ), but somehow I was able to link to it without issue.