Re: [MinGW-dvlpr] _MT and _DLL macros

[Greg C. <gch...@sb...>]

On 2012-08-21 18:15Z, Earnie Boyd wrote:
> So based on http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx and
> in particular the following text (each line is a column in the
> spreadsheet), since we are using MSVCRT or equivalent these should
> always be defined.  Thoughts?

I interpret it differently, as follows (I've transposed the last two
spreadsheet columns to the front):

If you run the ms compiler and linker with this switch:

> /MD

then they'll define these macros, which your code can rely on for
choosing among conditional sections:

> _MT, _DLL

and this CRT '.lib' file will be linked:

> msvcrt.lib

which is an import library for the following dll:

> msvcr110.dll

and here's a narrative description:

> Multithreaded, dynamic link (import library for MSVCR110.DLL). Be
> aware that if you use the Standard C++ Library, your program will need
> MSVCP110.DLL to run.

I haven't used their compiler in twenty years, so it's conceivable that
I've misunderstood. But note that the "Option" column that I moved to
the very front is the only one they set in boldface and made clickable,
which would seem to give it primacy. Click on it:
  http://msdn.microsoft.com/en-us/library/2kzt1wy3%28v=vs.80%29.aspx
and the same information appears in a different format that supports
the interpretation above, e.g.:
  Option: /MD
  Description: "Causes your application to use the multithread- and
  DLL-specific version of the run-time library. Defines _MT and _DLL
  and causes the compiler to place the library name MSVCRT.lib into
  the .obj file."
That implies that /MD is what governs, and the consequent use of MSVCRT
and definitions of some macros are among the effects that result.

If we want to define similar macros, they should indicate which compile
and link options were given to gcc. (There may be some reason to use our
own names--e.g., borland used __DLL__ instead of _DLL, but I don't know
the reason why.) But I would caution against adding any macros now: that
might break existing code, and AFAICR nobody has ever asked for such a
change. I'd just follow the digitalmars approach, because the reason
highlighted below applies to us as well:

http://www.digitalmars.com/ctg/ctgPorting.html
| Problem: _MT not automatically defined
| 32-bit Microsoft C++ sets _MT=1 if the /MT (multi-threaded) option is
| specified. If /MD (multi-threaded DLL) is specified, 32-bit Microsoft
| C++ sets _MT=1 and _DLL=1. Digital Mars C++ has no equivalent switches
| because its 32-bit run-time library is always multi-threaded. To solve
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [MinGW too]
| this problem, define _MT and _DLL on the dmc command line as necessary.