The use of -mno-cygwin at http://bit.ly/qAIsZV causes build failures with versions of MinGW GCC. For example http://bit.ly/llK3f3

I recently ran into it trying to build a Mercurial snapshot using a MinGW GCC v4.6.2 flavor http://pastie.org/2274486

Why is -mno-cygwin still be used, and is there any reason why it can't be removed?

Thanks, Jon

I can confirm the option has been removed. For those that don't want to believe a random person's comment on a bugtracker, here's the commit:

http://repo.or.cz/w/official-gcc.git/commit/2637551aa9314c46cf4205d435ab5e8944e9ac8a

The changelog is a bit cryptic, but note the last two items "removing documentation from removed option".

Hi! Thanks for the report. This can’t be fixed in 2.5, 2.6 or 3.1, which are in security-fix only mode, but we can do something for the active branches.

A quick web search finds reference of this deprecation/removal as far as 2007. Does anyone have more official documentation? If we can find the first gcc version that deprecates this option, then I’ll be able to make a patch with a version check (in order not to change previously working code).

(In the future, it would be nice of you not to use URL obfuscators or pastebins. Such services offer no guarantee of continued availability of hosted resources or links, but it is useful to keep information on this bug tracker for future reference. Thank you.

The first link is this: http://hg.python.org/cpython/file/4feb889d3bed/Lib/distutils/cygwinccompiler.py#l296
The second: http://stackoverflow.com/questions/6034390/compiling-with-cython-and-mingw-produces-gcc-error-unrecognized-command-line-op
The compile log from the third link is attached as a file.)

I forgot to answer this:

Why is -mno-cygwin still be used,
Simply because distutils had no dedicated maintainer for a long time, and because nobody was aware of this change. I don’t think any Python core developer is using Cygwin.

and is there any reason why it can't be removed?
For distutils, we have to work on eggshells when fixing bugs to make sure we don’t break third-party code that relies on known bugs or works around them. That’s why I propose adding a version check* instead of just removing the option.

• i.e. removing -mno-cygwin if self.gcc_version >= some version

Does anyone have more official documentation?

The commit I linked to has the full option removal at October 7 2010 (see the fifth item in the changelog entry). Any GCC (major) version released after that will have it completely removed.

Deprecation happened (according to the first doc change mentioning this option as being deprecated) on 2009-03-25: http://repo.or.cz/w/official-gcc.git/commit/6609be22531f447aeddbb3f670ad7883036cb23f

It looks like GCC 4.4 and up have this change in them, by looking at their commit logs. Anyone using GCC 4.3 on MinGW should be shot (but that's just my humble opinion, rather radical I admit ;-) )

Note this has really nothing to do with current Cygwin or the cygwin platform; MinGW was part of the Cygwin source for a long time, and every MinGW compiler was burdened to search the Cygwin header and lib paths. These commits fixed that problem.

MinGW(-w64) is a native compiler for Win32 just as MSVC is. Links to msvcrt.dll and has no POSIX translation/compatibility layer like the Cygwin DLL.

May I ask for a reconsideration to commit a fix for this for Python 2.7 at least? With the version check it doesn't hurt anyone, instead it helps prevent further confusion and support requests on the MinGW side. Distutils pop up everywhere, and the projects depending on them rely on them working correctly. Thanks

I have confirmed on Win7 that the following 32bit MinGW flavors still recognize -mno-cygwin option and build without error:

(4.5.2) http://tdm-gcc.tdragon.net/download

(4.5.4) http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/ using the mingw-w32-1.0-bin_i686-mingw_20110624.zip download

...by compiling with:

[i686-w64-mingw32-]gcc -Wall -mno-cygwin -o helloworld.exe helloworld.c

...where helloworld.c was:

#include <stdio.h>
int main(int argc, char *argv[]) { printf("Hello World!\n"); return 0; }

I have not yet checked the latest mingw.org download from the following, but I expect that it also recognizes -mno-cygwin. I will check later and report back if appropriate.

(4.5.2) http://sourceforge.net/projects/mingw/files/

Given Ruben's 4.4 comment, something is odd here. Looks like some gcc source spelunking as these doc links make no mention of the removal:

http://gcc.gnu.org/gcc-4.6/changes.html
http://gcc.gnu.org/gcc-4.5/changes.html
http://gcc.gnu.org/gcc-4.4/changes.html

and the gcc manual is inconsistent. This summary mentions the option

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Option-Summary.html#Option-Summary

but the details sections don't mention the option

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/i386-and-x86_002d64-Windows-Options.html#i386-and-x86_002d64-Windows-Options

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

Ah, our good friend grep.

should the question be "what's the first mingw gcc version that -mno-cygwin usage unnecessary" rather than finding the first version the option was removed?

and, does it matter whether you're building on win for win, or cross compiling for win from nix?

sadly, i don't know gcc internals but a post to the mingw and/or mingw-w64 ml's should get the right people weighing in.

btw, can distutils do a lightweight configure-like check for feature presence rather than going a gcc version check?

May I ask for a reconsideration to commit a fix for this for Python
2.7 at least? With the version check it doesn't hurt anyone
There’s a misunderstanding: I explained why 2.5, 2.6 and 3.1 can’t be fixed, but if you look at the versions at the top of this page, you’ll see 2.7, 3.2 and 3.3 listed. This will get fixed in these versions.

Ah, our good friend grep.
Thanks for the exploration. This looks complicated.

should the question be "what's the first mingw gcc version that
-mno-cygwin usage unnecessary" rather than finding the first version
the option was removed?
If removing the option in these versions causes no change (i.e. doesn’t break any code), I agree.

and, does it matter whether you're building on win for win, or cross
compiling for win from nix?
I’m afraid I don’t know enough about Windows and MinGW to answer that. If we can’t be sure about versions and consequences here, I’ll go to the MinGW ML.

btw, can distutils do a lightweight configure-like check for feature
presence rather than going a gcc version check?
There is a config command that’s not very used, but it would be IMO overkill to use it in the compiler code.

> and, does it matter whether you're building on win for win, or cross
> compiling for win from nix?
I’m afraid I don’t know enough about Windows and MinGW to answer that. If we can’t be sure about versions and consequences here, I’ll go to the MinGW ML.

Ruben's on it :)
http://sourceforge.net/mailarchive/message.php?msg_id=27864860

are you ok with a targeted patch similar to what's being discussed at

http://sourceforge.net/mailarchive/message.php?msg_id=27895558

assuming the regex search the output of gcc -dumpspecs idea is valid?

it is save to remove -mno-cygwin from Mingw32CCompiler

The necessity of walking on eggs with the distutils codebase restrains me. I’ve read the thread on sourceforge (thanks Ruben) but don’t have enough information yet to decide whether to do a version check, call gcc -dumpspecs or remove the option altogether.

BTW, there’s no need to use re.search if you’re not using a regular expression: “'no-cygwin' in output” will work.

shortly after opening this issue i removed -mno-cygwin from my 2.7.2 install and have had no issues on win7 32bit. but i understand you're hesitation.

regardless what you decide, please consider placing a summary note in the source comments as a safety net.

if you'd like me to try building a limited set of extensions to help with your decision, let me know. i have the following mingw toolchains on my win7 32bit system:

• tdm gcc 4.5.2 - http://tdm-gcc.tdragon.net/
• mingw-w64 prefix-stripped gcc 4.5.4 - http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/
• Ruben's gcc 4.6.2 personal build - http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/4.6.2-1/

i'm not speaking for Ruben, but as he maintains https://github.com/rubenvb/MinGW-w64-build-scripts you might try cajoling him if you feel you need more test results ;)

re: re.search, understood, thanks...quick-testing.

Would it be practical to have a trivial compilation test to see if we are capable of using GCC with -mno-cygwin and if so, use it, otherwise drop off? I think GNU autotools uses a similar strategy for detecting compiler capabilities.

Would it be practical to have a trivial compilation test to see if we
are capable of using GCC with -mno-cygwin and if so, use it, otherwise
drop off? I think GNU autotools uses a similar strategy for detecting
compiler capabilities.

The config command does such things, but the compiler classes don’t. I’d prefer something more lightweight, like a version check (see msg141231).

Just adding a data point: I use the "mingw32" compiler setting with the Cygwin GCC installation, to compile extensions for standard Windows Python (not Cygwin Python). It would be good if any change doesn't break this scenario -- assuming it's not already broken in newer Python versions.

(For this scenario, AFAIK, the no-cygwin option is required, or at least I believe it was the last time I intentionally compiled something.)

I've come across this issue when trying to build extensions for Python 3.3 on Windows, needing a recent enough MinGW to provide a library for msvcr100. See issue bpo-15315.

I have gcc 3.4.4 in my cygwin installation, and it still needs the -mno-cygwin option, else the resulting binary will link with cygwin1.dll (which is undesired).

I just installed the cygwin gcc4 package; this gives me gcc 4.5.3. In this version, -mno-cygwin is still recognized, and gives this error message:

gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.

So it seems that removing the -mno-cygwin flag is definitely incorrect, as it will result in a cygwin binary.

I then installed the mingw-gcc-core package, which gave me the utility i686-pc-mingw32-gcc, which indeed is able to create a (nearly) correct binary.

So I think we should check whether i686-pc-mingw32-gcc exists in the path, and if so, use it (without a -mno-cygwin flag). If it doesn't exist, we should continue to use gcc -mno-cygwin.

My remaining concern with i686-pc-mingw32-gcc is that it still links with msvcrt.dll in addition to linking with msvcrXY.dll; this is incorrect.

There is another concern that this applies to 32-bit mode only; in 64-bit mode, i686-w64-mingw32-gcc should be used. However, this is bpo-4709.

The 64-bit compiler is actually called x86_64-w64-mingw32-gcc.

It would be great if this could be sorted out in time for Python 3.3. Otherwise I don't think we'll be able to use MinGW to build extensions in Windows. Unless there is a version of MinGW which supports the -mno-cygwin option, as well as libmsvcr100.

Checking for a compiler's file name is stupid. Native Windows gcc is just "gcc.exe", Cygwin native GCC is also "gcc". Some have a lot of toolchains in PATH at the same time. That's not the right way to handle this kind of thing.

*bump*

I just installed MinGW 2.6.2 32-bit on Windows XP. It doesn't accept -mnocygwin and there is no binary "i686-pc-mingw32-gcc" either.

It would be great if you could agree on an approach and get this fixed. This impacts a lot of users that want to build extensions on Windows. In the mean time users can find a hack to work around the issue here: https://gist.github.com/4466320

Don’t forget that distutils is used during CPython’s build process to compile extension modules: subprocess may not be importable then.

On 9 July 2013 17:36, Éric Araujo <report@bugs.python.org> wrote:

Don’t forget that distutils is used during CPython’s build process to compile extension modules: subprocess may not be importable then.

Subprocess is imported at at the top of the module in 3.x [1]. The
whole distutils.cygwinccompiler module is an ImportError if subprocess
is not importable.

Or did you mean for 2.7 only (where get_versions() uses os.popen)?

[1] http://hg.python.org/cpython/file/3f3cbfd52f94/Lib/distutils/cygwinccompiler.py#l51

I'm attaching three new patches following on from Eric and Christian's
suggestions:

check_mno_cywin_py27_1.patch (for Python 2.7)
check_mno_cywin_py3_1.patch (for Python 3.2 and 3.3)
check_mno_cywin_py34_1.patch (for Python 3.4)

The py27 patch now uses os.popen to avoid importing subprocess as
suggested by Eric. The other two patches are changed to use
check_output as suggested by Christian (subprocess is already imported
in 3.x).

I've retested the patches using the same setup as before and the
results are unchanged for all gcc and Python versions tested.

*bump*.

This is a critical bugfix that prevents I bet 90%+ of Python users on Windows compiling C extensions. It has been open for 2 years and it's a great disservice to people having to compile stuff on Windows.

Oscar has been doing a terrific job of providing man patches. May I ask that a core dev finally takes some responsibility here, signs of on the patch, and get it applied?

I just noticed today that the fix that implemented by these patches
(only providing -mno-cygwin if gcc_ver < 4) is also used by numpy's
distutils. You can see the relevant code here:

https://github.com/numpy/numpy/blob/master/numpy/distutils/mingw32ccompiler.py#L117

The relevant commit was three years ago:

numpy/numpy@9dd7c7b

They haven't bothered with checking for cygwin gcc (my patches only do
this to try and show a helpful error message).

Oscar, thanks for the patches. Two things:

• in the 2.7 patch, could you explicitly close the popen() file object instead of relying on deallocation to do it?
• have you signed a contributor's agreement? http://www.python.org/psf/contrib/

Thanks for looking at this Antoine.

I've attached an updated patch for Python 2.7 called
check_mno_cywin_py27_2.patch. This explicitly closes the popen object
in the same way as the get_versions() function immediately above.

I've just signed an electronic contributor's agreement.

On 30 September 2013 12:08, Oscar Benjamin <report@bugs.python.org> wrote:

I've attached an updated patch for Python 2.7 called
check_mno_cywin_py27_2.patch.

To be clear: I retested this patch (using the setup described above)
and the results are unchanged.

New changeset 7d9a1aa8d95e by Antoine Pitrou in branch '2.7':
Issue bpo-12641: Avoid passing "-mno-cygwin" to the mingw32 compiler, except when necessary.
http://hg.python.org/cpython/rev/7d9a1aa8d95e

New changeset 6b89176f1be5 by Antoine Pitrou in branch '3.3':
Issue bpo-12641: Avoid passing "-mno-cygwin" to the mingw32 compiler, except when necessary.
http://hg.python.org/cpython/rev/6b89176f1be5

New changeset 8e180b2067e4 by Antoine Pitrou in branch 'default':
Issue bpo-12641: Avoid passing "-mno-cygwin" to the mingw32 compiler, except when necessary.
http://hg.python.org/cpython/rev/8e180b2067e4

Thank you Oscar! This issue can endly be fixed.

Thanks Antoine!

This is broken for Python 2.7.4. Is it fixed in 2.7.6? gcc deprecated -mno-cygwin. It's not there any more. There shouldn't be a discussion. This is an incredibly poor example of how fragmentation and poor process result in poor quality open source software--in the corners, even when the overall code is excellent. Over 2 years on something this trivial. Hundreds of lines of discussion. There wasn't really any reason for this to have persisted.

This is broken for Python 2.7.4. Is it fixed in 2.7.6?

The fix is in 2.7.6, yes.

I'm seeing this bug in 2.7.9. The reason seems to be that the version detection doesn't work...

This snippet:

  out = os.popen(gcc_exe + ' -dumpversion', 'r')
  out_string = out.read()

returns an empty out_string, causing gcc_version = None < '4'

Maybe the < '4' check could be restructured to see None as "probably modern" instead of "probably very out of date" ?

Michael, this issue is closed and the changes have long since been released. Comments here will likely be ignored. Please open a new issue describing the problem you are seeing and under what environment, with exact steps to reproduce it.