On 21 May 2013 17:21, Martin v. Löwis <report@bugs.python.org> wrote:
>
> C: Users who have only cygwin gcc 4.x installed
>
> For those, the current setup will produce an error message, essentially telling them that the need to fix something (specifically: edit distutils, install mingw). With the proposed change, --compiler=mingw32 will produce a binary, but the binary will incorrectly depend on cygwin. They may not notice on their local system (since cygwin.dll is available), but only on customer systems.

Well there cannot be anyone in group C who currently has a functioning
setup. But I agree that it's better to have a good error message. It
may be possible to check in some way that the gcc used is from cygwin
and add an error message specifically for this case. I'll have a look
at this when I'm next on Windows.

More generally I think that compiling non-cygwin extensions with
cygwin gcc should be altogether deprecated (for Python 3.4 at least).
It should be discouraged in the docs and unsupported in the future. It
can only work with -mno-cygwin which in turn only works with gcc 3.x,
has never documented as being a stable gcc feature, is now abandoned
and is referred to disparagingly on both the mingw and cygwin mailing
lists:

To quote Dave Korn from cygwin http://cygwin.com/ml/cygwin/2009-03/msg00802.html
'''
  gcc-3 -mno-cygwin still works just as well (or badly!) as it ever has done,
and will be retained for ever.

  gcc-4 series releases will not support it at all.  As the whole thing is
(still) experimental and explicitly warned to be unstable I don't see the need
to go for a deprecation period.
'''

Or Earnie Boyd from mingw-users
http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42111
'''
On Mon, May 20, 2013 at 9:13 AM, Paul Moore wrote:
> So building an extension using --compiler=mingw in Python could pick up a
> cygwin gcc if that was on PATH, and this will work as long as -mno-cygwin is
> passed on the command line. But it won't work (it will build a DLL with a
> dependency on the cygwin DLL) if -mno-cygwin is omitted. I'd argue that
> people should just install and use mingw rather than cygwin, but that may
> not be what everyone does in practice.

No!!! The -mno-cygwin abomination is dead.  If you want to build a
native Python using Cygwin you would do it the cross compiler way and
state the --host you're configuring for.  Python's distutil needs to
remove the -mno-cygwin option.
'''

However no-cygwin mode is currently a documented feature:
http://docs.python.org/3.4/install/index.html#gnu-c-cygwin-mingw

So it can't simply be deprecated in already released Pythons but I do
want to fix the mingw bug there if possible. The suggestion to make
-mno-cygwin conditional on gcc major version may lead to some users
who attempt to use a setup that did not previously work not seeing the
appropriate error message. However it does, I believe, come with the
following two guarantees:

   1) Mingw setups that are used, wanted and currently broken will be fixed.
   2) No currently functional setups will be broken.

That may be the best that is possible given the tight constraints on
changes to distutils.

> That said: which of Roumen's patches (if any) would you recommend for inclusion?

None. I may have misread them but my impression is that they are not
particularly intended to be used as individual patches. I can't see
one that just makes the relevant changes and collectively they make up
a more pervasive change than I was proposing.

The patch that I was proposing for 3.4 would simply remove -mno-cygwin
on these 5 lines:
http://hg.python.org/cpython/file/7fce9186accb/Lib/distutils/cygwinccompiler.py#l322

For 2.7, 3.2 and 3.3 I would do the same but conditional on self.gcc_version.

I think Roumen has identified many different issues but I would try
and keep it focussed on the one -mno-cygwin  issue.

Oscar