Question

I build /mt (run-time library:multi-threaded) and /md (run-time library:multi-threaded-dll) versions of my C++ DLL with visual studio 2008.

Applications which link to the /md build runs fine,
but applications which link to the /mt build crash.

Interestingly applications which link to the static version of the /mt build work fine.

Does it make sense to build a DLL with /mt and use it with an application which is also built with /mt?

How can I trace the reason for this sort of crash?

Regards,

Paul

Answer 1

It depends on your API. If you build your executables with the non-DLL version of the run time libraries then each DLL and EXE gets it’s own copy of the static data of the run time libraries. The most obvious effect is that you can’t allocate something dynamically from one module (DLL or EXE) and expect to safely free it in another module. There going to be other less common issues, for example if you srand in one module, don’t expect it to affect calls to rand across the application.

It’s generally safest in an executable that links against other user DLLs to compile them all against the DLL version of the run time libraries. You might want to use the static versions of the run time libraries if you were building a statically linked executable using static libraries, perhaps for ease of packaging and distribution but I don’t see much benefit in a hybrid configuration given the potential issues.