- #MINGW OR CYGWIN MANUAL#
- #MINGW OR CYGWIN PATCH#
- #MINGW OR CYGWIN FULL#
- #MINGW OR CYGWIN CODE#
- #MINGW OR CYGWIN DOWNLOAD#
> May I ask for a reconsideration to commit a fix for this for Python 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.ītw, can distutils do a lightweight configure-like check for feature presence rather than going a gcc version check? 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?Īnd, does it matter whether you're building on win for win, or cross compiling for win from nix?
This summary mentions the optionīut the details sections don't mention the option
#MINGW OR CYGWIN MANUAL#
Looks like some gcc source spelunking as these doc links make no mention of the removal:Īnd the gcc manual is inconsistent. Given Ruben's 4.4 comment, something is odd here. I will check later and report back if appropriate.
#MINGW OR CYGWIN DOWNLOAD#
I have not yet checked the latest download from the following, but I expect that it also recognizes -mno-cygwin. Gcc -Wall -mno-cygwin -o helloworld.exe helloworld.c I have confirmed on Win7 that the following 32bit MinGW flavors still recognize -mno-cygwin option and build without error: Distutils pop up everywhere, and the projects depending on them rely on them working correctly.
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. Links to msvcrt.dll and has no POSIX translation/compatibility layer like the Cygwin DLL. MinGW(-w64) is a native compiler for Win32 just as MSVC is. 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. Anyone using GCC 4.3 on MinGW should be shot (but that's just my humble opinion, rather radical I admit -) ) It looks like GCC 4.4 and up have this change in them, by looking at their commit logs. Any GCC (major) version released after that will have it completely removed.ĭeprecation happened (according to the first doc change mentioning this option as being deprecated) on :
#MINGW OR CYGWIN FULL#
The commit I linked to has the full option removal at Octo(see the fifth item in the changelog entry).
> Does anyone have more official documentation? removing -mno-cygwin if self.gcc_version >= some version That’s why I propose adding a version check* instead of just removing the option.
#MINGW OR CYGWIN CODE#
> and is there any reason why it can't be removed?įor 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. I don’t think any Python core developer is using Cygwin. Simply because distutils had no dedicated maintainer for a long time, and because nobody was aware of this change. The compile log from the third link is attached as a file.) 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. (In the future, it would be nice of you not to use URL obfuscators or pastebins.
#MINGW OR CYGWIN PATCH#
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). 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.Ī quick web search finds reference of this deprecation/removal as far as 2007. The changelog is a bit cryptic, but note the last two items "removing documentation from removed option". For those that don't want to believe a random person's comment on a bugtracker, here's the commit: I can confirm the option has been removed. Why is -mno-cygwin still be used, and is there any reason why it can't be removed? I recently ran into it trying to build a Mercurial snapshot using a MinGW GCC v4.6.2 flavor The use of -mno-cygwin at causes build failures with versions of MinGW GCC. Issue12641-modernize_cygwin&mingw_Ġ001-MINGW-issue12641-customize-mingw-cygwin-compilers.patchĠ001-MINGW-issue12641-check-if-cygwin-mingw-compiler-supp.patchĠ001-MINGW-issue12641-avoid-syntax-warning.patch Jeffrey.Armstrong, Martin.Fiers, Michael.Clerx, Pete.Forman, RubyTuesdayDONO, Seppo.Yli-Olli, alexis, christian.heimes, cmcqueen1975, danmbox, doko, eric.araujo, fratti, gaudyallure52, geertj, honorableinvasi, jkloth, jonforums, jwilk, lemburg, lewisl, loewis, ned.deily, oscarbenjamin, paul.moore, pitrou, pje, python-dev, rivy, rpetrov, rubenvb, santoso.wijaya, schmir, stakingrainbow2, tarekĬreated on 17:02 by jonforums, last changed 01:46 by ned.deily.
0 kommentar(er)
