Re: /MD vs /MT
On Tue, 27 May 2008 15:06:34 -0700 (PDT), mathieu
<mathieu.malaterre@gmail.com> wrote:
Hi there,
I would like to know what are the subtle differences in between an
app+libs compiled with /MD versus an app+libs compiled with /MT.
Summary of issue:
I am getting a segfault when building my pet project 'gdcm' using /MT
while nothing seems to be going on wrong using /MD (linux+gcc seems to
be fine too).
The /MD option causes you to use the multithreaded CRT in DLL form, while
/MT causes you to use the multithreaded CRT in static library form. If your
"app+libs" means EXE plus static libraries, then of course all must use the
same CRT flavor and be compiled with the same compiler version. If your
"app+libs" means EXE plus DLLs, and you expect them to share CRT state such
as the heap, C-level file descriptors, and so forth, you must consider it
equivalent to static linking WRT compilation dependencies, plus you must
link everyone to the same CRT DLL. Call this "Case 1". Only a DLL that is
treated as a black box, which shares no state with anyone, and which only
exposes a C-like API, may choose its CRT independently of its clients. Call
this "Case 2".
I searched through the svn history and found the latest working rev
to be 2848, what I did at rev 2849 is simply move one main C++ class
from a shared lib to another:
http://gdcm.svn.sourceforge.net/viewvc/gdcm?view=rev&revision=2849
If the C++ class is shared between modules (EXE and DLLs), you almost
certainly have the "Case 1" scenario described above. Given that /MD works
while /MT doesn't, I'd suspect that the other modules you link to are using
/MD. Thus, when you use /MT, and you try to delete an object that was
created in a /MD module, you end up trying to return it to the wrong heap,
or when you use a file descriptor that was created in a /MD module, you end
up using an empy IO block, etc etc etc.
--
Doug Harrison
Visual C++ MVP