Oscar Benjamin added the comment: On 21 May 2013 17:21, Martin v. Löwis <rep...@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 ---------- _______________________________________ 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
