From: Oscar B. <osc...@gm...> - 2013-05-21 11:34:34
|
On 20 May 2013 16:58, Greg Chicares <gch...@sb...> wrote: > On 2013-05-20 14:54Z, Paul Moore wrote: > [...] >> The OP is trying to gather evidence that it is *not possible* for people to >> be relying on the existing broken behaviour, because it cannot produce >> viable executables (the only versions of gcc that could exist anywhere >> which accept -mno-cygwin, do not support building with the version of >> MSVCRT that Python needs). If he can *prove* that there are no users who >> will be adversely impacted by the change, it might be possible to get the >> change moving at last. > > 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. Brilliant. Thanks for that. The next part of that message is also very interesting: | 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. I guess that means that cygwin users of the arrangement that Paul described should also see this bug when using any gcc 4.x. This is certainly true of gcc 4.5.3 in my own old and unused cygwin installation: $ gcc --version gcc (GCC) 4.5.3 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc hello.c $ ./a.exe Hello World $ gcc -mno-cygwin hello.c gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. If there were people using distutils' mingw32 mode with cygwin's gcc I would have expected this to have been reported on the Python issue tracker but it is not. This seems like reasonable evidence that people are not actually using this setup even if I can't prove that it is impossible. > Some people may still be using Cygwin gcc version 3, which needs > '-mno-cygwin'. Those are the only people who might be affected. This is the only possible breakage and it concerns a possibly non-existent group of users who are abusing distutils' mingw32 mode to compile with a now-abandoned, experimental feature of a legacy cygwin compiler. Hopefully this obscure, possible breakage can be outweighed by the definite, known breakage in distutils' support for using any recent and future mingw compilers in the appropriate way as described in the distutils docs. Thanks everyone. I think I have more than enough information now. I'll take this over to the Python issue tracker. Oscar |