Answered by:
Linking /MT library into a /MD managed c++ project

Question
-
We're trying to link a managed c++ project /clr, which is inherently a /MD project, with some infrastructure libraries, which are all built as /MT and there's no way to change that.
So far we were able to build the project in V90. In order to do so we had to ignore msvcprtd.lib and Libcmtd.lib using the "Ignore Specific Default Libraries" property. This worked well for us.
The issues began when we migrated to V120. Now we are always getting the following error:
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'
Was this added in VS 2013?
Is there any way to ignore this error?
Thanks!
Jonathan S.
BTW, We're fully aware of the risks in combining /MT and /MD libraries.
Tuesday, August 25, 2015 9:01 AM
Answers
-
Well you do have two fundamentally conflicting options -- CLR requires /MD and if you cannot modify the library to use /MT then you are stuck. (Most commercial libraries come in both flavors to help alleviate this problem)
The only workaround I could think of would be to put either the CLR code or the other library code into a DLL then expose a raw C interface for the DLL. That would permit both sets of code to be in use in a single process at the same time, but requires segregating the parts of the project and a carefully written interface between the two parts.
Tuesday, August 25, 2015 2:32 PM
All replies
-
The error is generated through the #pragma detect_mismatch which seems to have been implemented beginning in VS2010. I'm not aware of any way to override or ignore this error other than by conforming the use of /MT and /MD across the board.
Tuesday, August 25, 2015 12:23 PM -
Well you do have two fundamentally conflicting options -- CLR requires /MD and if you cannot modify the library to use /MT then you are stuck. (Most commercial libraries come in both flavors to help alleviate this problem)
The only workaround I could think of would be to put either the CLR code or the other library code into a DLL then expose a raw C interface for the DLL. That would permit both sets of code to be in use in a single process at the same time, but requires segregating the parts of the project and a carefully written interface between the two parts.
Tuesday, August 25, 2015 2:32 PM -
Just curious to know did you ignored those libraries or corresponding libraries in your VS 2013 as well or not.
Thanks
Rupesh Shukla
Tuesday, August 25, 2015 6:24 PM -
could this interface be a DLL with an import library (thus linked to the project), or will this DLL have to be loaded using the loadLibrary method avoiding any chance of linking errors?
Thanks
Tuesday, August 25, 2015 10:40 PM -
I've tried both configurations and unfortunately the result remained the sameTuesday, August 25, 2015 10:41 PM