Re: [PATCH, 3/4] Enable libstdc++ DLL: _GLIBCXX_DLL

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

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
defining _DLL?

> 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
> default.

  This patch follows the current MinGW release approach.  If you wanted to
make it automatic, a spec like

"{!%static{!%static-libstdc++:-D_GLIBCXX_IMPORT='__attribute__((dllimport))'}}"

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.

    cheers,
      DaveK