Kai Tietz wrote:
> 2009/7/18 Dave Korn <[email protected]>:
>> 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?)
>> 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?