This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author oscarbenjamin
Recipients Jeffrey.Armstrong, Martin.Fiers, Pete.Forman, RubyTuesdayDONO, Seppo.Yli-Olli, alexis, cmcqueen1975, danmbox, doko, eric.araujo, geertj, jonforums, jwilk, loewis, oscarbenjamin, paul.moore, pje, rpetrov, rubenvb, santoso.wijaya, schmir, tarek
Date 2013-05-22.12:40:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On 22 May 2013 12:43, Martin v. Löwis <> wrote:
> Am 21.05.13 23:14, schrieb Oscar Benjamin:
>> 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.
> I agree with that,


> although I find it sad that the Cygwin project
> apparently abandoned support for building Mingw binaries.

I don't understand their reasoning but given the scorn poured on to
-mno-cygwin from at least some people I trust that they had some good
reason :)

Also they have replaced it with something that they consider more
appropriate (the cross-compilers).

>> It can only work with -mno-cygwin
> This is factually incorrect. It also works with the i686-pc-mingw32-gcc
> executable, which (IIUC) is still available for Cygwin.

I should have been slightly clearer. It can only currently work in
distutils with -mno-cygwin. The executable you refer to is part of
cygwin gcc's cross-compiler toolchain. This is their recommended
replacement for -mno-cygwin (if not mingw) but is AFAICT unsupported
by distutils.

I think there's a case for saying that distutils should support these
but it should only be done with a new UnixCCompiler subclass and a new
--compiler entry point. It should also perhaps provide a way to
specify the --host since I think that facility is part of the purpose
of the new toolchain.

In any case cygwin cross-compiler support should not be conflated in
the codebase with distutils' mingw support and if it is to be added
that should be discussed in a separate issue. I personally don't think
I would use it and would not push for the support to be added.

Going back to the group C users: I think that it should be possible to
create an is_cygwingcc() function that would parse the output of 'gcc
--version'. Then Mingw32CCompiler.__init__ could do:

    if is_cygwingcc() and self.gcc_version >= '4':
        raise RuntimeError('No cygwin mode only works with gcc-3. Use
gcc-3 or mingw')

The is_cygwingcc() function can be conservative since false positives
or more of a problem than false negatives. I think this should address
your concern.

However on further reflection I'm a little reluctant to force an error
if I can't *prove* that the setup is broken. I'm no stranger to
monkey-patching distutils and it's possible that someone has already
monkey-patched it to make some bizarre setup just about work. I would
be a little peeved if my setup broke in a bugfix release simply
because someone else who didn't understand it decided that it wasn't
viable. (The same monkey-patching concerns apply to the other changes
but I think that fixing the non-monkey-patched setup for mingw trumps
in that case.) So perhaps the best place to deal with the
gcc-4/no-cygwin issue is in the distutils docs.

My updated proposal is (I'll write patches if this is acceptable):

Python 3.4:
Remove '-mno-cygwin'. This breaks the no-cygwin mode and fixes the
mingw mode. The distutils docs are updated with something like:
Note: Previous Python versions supported another 'no-cygwin' mode that
could use cygwin gcc to build extensions without a dependency on
cygwin.dll. This is no longer supported.

New in Python 3.4: No-cygwin mode is no longer supported.

Python 2.7, 3.2 and 3.3:
Only use '-mno-cygwin' if self.gcc_version < '4'. This should not
break any currently functioning setups (barring serious
monkey-patching). The distutils docs are updated with something like:
Note: The no-cygwin mode only works with cygwin's gcc-3. For gcc-4 it
may produce .pyd files with dependencies on cygwin.dll that are not
fully redistributable. The use of no-cygwin mode is deprecated by
cygwin and support for it is removed in Python 3.4.

If you would rather have the is_cygwingcc() check I'm happy to put
that in also if it gets this issue moving but I'm personally cautious
about it.

Date User Action Args
2013-05-22 12:40:58oscarbenjaminsetrecipients: + oscarbenjamin, loewis, doko, paul.moore, pje, geertj, schmir, tarek, jwilk, eric.araujo, rpetrov, cmcqueen1975, rubenvb, santoso.wijaya, alexis, Seppo.Yli-Olli, jonforums, RubyTuesdayDONO, Jeffrey.Armstrong, danmbox, Martin.Fiers, Pete.Forman
2013-05-22 12:40:58oscarbenjaminlinkissue12641 messages
2013-05-22 12:40:57oscarbenjamincreate