Re: [PATCH, 3/4] Enable libstdc++ as a DLL on windows platforms.

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Kai Tietz wrote:
> I strongly agree tp Charles here, that the use of _DLL is wrong.

Uh, that's not what I said.  I was asking the question, not stating that
Dave's approach was wrong.

> Even
> for VS it is just defined when shared (so called Mutlithread)
> C-Runtime is used.

False. VS uses -D_MT when compiling objects intended to link against the
multithread-capable runtime(s), whether those runtimes are DLLs or
static libraries.

VS uses -D_DLL when compiling objects intended to link against the
(import libraries of) DLL runtime(s), exactly as Dave is proposing here.

> It has absolutely nothing to do, with DLL
> compilation.

And as used in Dave's patch, it also has nothing to do with compiling
client DLLs (or, for that matter, compiling libstdc++ as a DLL itself):
  End users should define _DLL when compiling objects that, when linked,
  will be linked against the shared libstdc++, whether the user is
  trying to create a DLL or an EXE.  It should not be defined in any
  other context.
This is exactly how that macro is used in visual studio.

Whether we arrange that this (-D_DLL) is done for the end user
automatically, as part of some default setting in specs or whatever, is
a separate issue.

> Please see for details
> http://msdn.microsoft.com/en-us/library/b0084kay(VS.80).aspx

You've found a thinko in MS's documentation. The page you reference states:

 _DLL	Defined when /MD or /MDd (Multithread DLL) is specified.

But that's because *all* MS DLL runtimes are multithreaded. They could
easily have stated:

 _DLL	Defined when /MD or /MDd (one of the DLL runtimes) is specified.

That is, it's not the fact that these are "multithread" that is the
issue, but that they are "DLLs". This is made clear from the page *I*
referenced.
  http://msdn.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx
It shows that _DLL should be defined by clients when linking against
(the import libraries of) any of the shared runtimes. It just so happens
that MS has never(?) supplied a shared runtime that is not also
multi-threaded (they do support a multi-threaded runtime that is not
shared, however -- and for that one, you do NOT use _DLL, only _MT):

LIBCMT.LIB 	Multithreaded, static link 	/MT 	_MT

> I know that we have at some points this assumption, but it is wrong
> and we should change this kind of definition, at least for none cygwin
> win32 targets.

No, actually I believe your statement is wrong, Kai.

--
Chuck