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

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Kai Tietz wrote:
> 2009/7/18 Dave Korn <dave.korn.cygwin@googlemail.com>:
>> Kai Tietz wrote:
>>
>>> Well, my concerns here are more in a general way of users using gcc
>>> for compiling source code written for windows. Believe me there are
>>> many projects (like mozilla, reactos, boehm-gc, ...) which want to
>>> compile their sources with VS and gcc. For those users the mis-use (in
>>> their opinion) of the _DLL macro is very annoying. This was the reason
>>> why I have the strong opinion here, that gcc shouldn't use this macro
>>> for win32 targets.
>>  Well, surely if they're compiling for MSVC using -D_DLL in order to get the
>> DLL version of the runtime libs, when they compile under GCC they will also
>> want to get the DLL version of the runtime libs?  (Ideally their configure
>> scripts will define it or not according to --enable/disable-static/shared?)  I
>> don't quite see why it would be misuse to make the GCC toolchain respond to
>> -D_DLL in the same way as the MSVC one, and isn't that what would result in
>> this case?
> You miss the point that VC defines _DLL automatically. This macro
> isn't user controlled. It is a builtin macro, like __FILE__, or
> _WIN32. The problem occurs, when users want to include headers from a
> library using _DLL for making decisions about dllimport or static API.

  Ok, so should MinGW un/define _DLL automatically using a builtin predefine
or spec option, based on whether static or shared linking is in use?
Presumably any such library that uses _DLL in its headers must be happy with
the import/no-import decision being made on the same basis as the
shared/static runtime decision, since it uses the same symbol that the MS
language runtime uses?

    cheers,
      DaveK