Oscar Benjamin added the comment:

I'd really like to get a resolution on this issue so I've tried to gather some 
more information about this problem by asking some questions in the mingw-users 
mailing list. The resulting thread can be found here:
http://comments.gmane.org/gmane.comp.gnu.mingw.user/42092

This issue concerns users of distutils --compiler=mingw32 mode. Normally this 
is used to build with mingw gcc in which case it is currently broken because of 
-mno-cygwin. It has been suggested above that some may be using it to build 
with cygwin's gcc. The -mno-cygwin option is there for those using cygwin's gcc.

To summarise the points (see the thread on mingw-users for more info):
1) -mno-cygwin has never had a meaningful effect in mingw.
2) -mno-cygwin produces an error in recent (~2011 onwards) mingw releases and 
will do for all future releases. This prevents distutils from building 
extensions with mingw.
3) -mno-cygwin only ever had a meaningful effect for cygwin's gcc 3.x where it 
could be used to build binaries that did not depend in cygwin.dll.
4) -mno-cygwin was always considered an experimental feature and its use is 
discouraged.
5) -mno-cygwin was removed from cygwin's gcc in the transition from 3.x to 4.x 
without any deprecation period (as it was an experimental feature). In gcc 4.x 
it produces an error preventing build.
6) The recommended way to replace the -mno-cygwin option is either to use mingw 
or to use cygwin's cross-compilers.

So there are two types of breakage affected by -mno-cygwin:

A: Anyone trying to use recent and future mingw versions to build extensions 
with distutils in the way that is described in the distutils docs. For this 
group distutils has been broken for 2 years and will continue to be until the 
-mno-cygwin option is removed.

B: Anyone who is using distutils with --compiler=mingw32 but using cygwin's gcc 
3.x instead of mingw's gcc to build an extension for a non-cygwin Python. For 
this group removing the -mno-cygwin option would result in unusable extension 
modules. (the resulting .pyd requires cygwin.dll but is to be used in a 
non-cygwin Python).

Firstly, note that users in group B must surely be a group that diminishes with 
time since they are using the legacy gcc 3.x cygwin compiler. Similarly, since 
neither of mingw or cygwin will ever bring back -mno-cygwin users in group A 
will only increase with time. (I am such a user and have been manually removing 
all reference to -mno-cygwin from distutils for 2 years now.) This means that 
the balance of breakage will only move towards group A over time.

Secondly, any users in group B will suffer the same problem as users in group A 
if they try to use gcc 4.x. However this has not been reported on the tracker 
(I read through all matches in a search for '-mno-cygwin'). I think this serves 
as an indication of how many people are actually using this setup.

Thirdly, the -mno-cygwin option is a now-abandoned, experimental feature of a 
legacy compiler. Its creators did not feel the need to give it a deprecation 
period and its use is discouraged by both mingw and cygwin.

Bringing these points together: not removing -mno-cygwin from distutils trades 
the possible breakage for possibly non-existent users of the obscure, legacy, 
and generally considered broken setup B against the definite, known breakage 
for users of the appropriate documented setup A. I think this should be enough 
to say that the fix for the next Python version should simply remove all 
reference to '-mno-cygwin' as I have been doing for 2 years now without 
problem. The only users who can be adversely affected by this are those in 
group B who decide to upgrade to non-cygwin Python 3.4 (while still using an 
ancient cygwin gcc to build extensions). The suggested fix can be either to use 
mingw or to setup the cross-compilers in their cygwin installation.

For Python 2.7, 3.2 and 3.3 I think that this should be considered a bug that 
can be fixed in a bugfix release. However in that case it may be considered 
inappropriate to risk the small possibility of users in group B experiencing 
breakage. Since such users must be using cygwin's gcc 3.x, I propose that 
distutils check the gcc version and only add '-mno-cygwin' if the major version 
is 3. This will not adversely affect users in group B and will fix the problem 
for users in group A. Users in group B who attempt to use gcc 4.x will find 
that they get a different error message (at import time instead of build time) 
but that their setup will still be just as broken as it was before this change.

Thanks,
Oscar

----------
nosy: +oscarbenjamin

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to