Aaron W. LaFramboise wrote:
> 1) Regardless of what _DLL is supposed to do, and how we should support
> it to try to be compatible with MSVC, I do not think MinGW should use
> _DLL to control whether libstdc++-v3 is dynamically linked. Getting
> _DLL semantics to make sense, in the context of a runtime split between
> different libraries and projects, is nontrivial, and we should not tie
> libstdc++-v3 to it.
> I would prefer something like _GLIBCXX_DLL, that makes it namespace and
> purpose clear, and unlike to conflict with other meanings.
> If we want to tweak or improve the semantics of _DLL later, we certainly
> can do something to make _DLL define _GLIBCXX_DLL or whatever, but lets
> keep that insanity out of this patch.
The insanity is out of this patch; this patch doesn't yet decide how MinGW
sets _GLIBCXX_IMPORT. It only tests for _DLL on Cygwin.
Come to think of it, if you want this kind of name, why not just directly
define _GLIBCXX_IMPORT (to "__attribute__ ((dllimport))" wherever you would be
> 2) Where is _DLL/_GLIBCXX_DLL is supposed to be defined? Current MinGW
> release takes the approach of requiring the user to define it, but I'm
> not sure that this is really a good idea, particularly if dynamic is the
This patch follows the current MinGW release approach. If you wanted to
make it automatic, a spec like
would do the job, wouldn't it?
I didn't figure leaving it up to the user was such a bad thing to do. It
gives them the choice of auto-import, and having slightly more efficient
access to data imports at the cost of slower start-up and less memory page
sharing, versus explicit dllimports everywhere and having to access data items
through indirect references.