On 24 June 2013 09:07, Marc-Andre Lemburg <report@bugs.python.org> wrote:
>
> Could someone perhaps produce a single final patch file which can
> be applied to Python 2.7 and 3.2+ ?

I've attached two patches "check_mno_cywin_py27.patch" for Python 2.7
and "check_mno_cywin_py3.patch" for Python 3.2 and 3.3. The changes
are identical but the 2.7 patch didn't apply cleanly against 3.x. I'll
upload the files used to test the patches in "test_mno_cygwin.tar.gz".

The patches are as I described previously and check the output of 'gcc
-dumpmachine' to see if the gcc on PATH is from cygwin. With the patch
'-mno-cygwin' will be passed if gcc version < 4 or the gcc is from
cygwin. Otherwise it will not be passed.

I've tested with versions:
Python 2.7.5, 3.2.5 and 3.3.2
MinGW gcc 4.7.2
Cygwin gcc 3.4.4 and 4.5.3

The results of the patch are the same for all versions of Python tested:
Cygwin gcc 3.x - still works
Cygwin gcc 4.x - still doesn't work (same error message)
MinGW gcc 4.7  - fixed after the patch

This patch does not attempt to add support for the newer (gcc 4.x)
Cygwin cross-compilers. I have experimented with what it would take to
have those work and it is something like:

if is_cygwingcc() and version >= 4:
    platform = platform_map[get_platform()]
    use platform + '-pc-cygwin-gcc' as gcc
    use platform + '-pc-cygwin-g++' as g++
    etc.

Then there would also need to modifications to the linker settings to
fix the problem that Martin mentioned (a long way above) that it would
link against the wrong MSVC runtime. I started writing the patch to do
these things as well as fix MinGW support and it became more and more
of a mess. I don't think that distutils should be trying to guess
whether or not people intended to use the Cygwin cross-compilers. If
these are to be supported then they should have a new
--compiler=cygwin-cross and a separate subclass of CygwinCCompiler to
avoid more issues like this one arising in the future.

Oscar