[issue12641] Remove -mno-cygwin from distutils

Ned Deily added the comment: 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. -- nosy: +ned.d

[issue12641] Remove -mno-cygwin from distutils

Michael Clerx added the comment: 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 <

[issue12641] Remove -mno-cygwin from distutils

Antoine Pitrou added the comment: > This is broken for Python 2.7.4. Is it fixed in 2.7.6? The fix is in 2.7.6, yes. -- ___ Python tracker ___

[issue12641] Remove -mno-cygwin from distutils

Lewis Levin added the comment: 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-

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: Thanks Antoine! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue12641] Remove -mno-cygwin from distutils

Antoine Pitrou added the comment: Thank you Oscar! This issue can endly be fixed. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker __

[issue12641] Remove -mno-cygwin from distutils

Roundup Robot added the comment: New changeset 6b89176f1be5 by Antoine Pitrou in branch '3.3': Issue #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'

[issue12641] Remove -mno-cygwin from distutils

Roundup Robot added the comment: New changeset 7d9a1aa8d95e by Antoine Pitrou in branch '2.7': Issue #12641: Avoid passing "-mno-cygwin" to the mingw32 compiler, except when necessary. http://hg.python.org/cpython/rev/7d9a1aa8d95e -- nosy: +python-dev __

[issue12641] Remove -mno-cygwin from distutils

Changes by Antoine Pitrou : -- assignee: eric.araujo -> pitrou stage: -> commit review versions: -Python 3.2 ___ Python tracker ___

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 30 September 2013 12:08, Oscar Benjamin 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. -- ___

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: 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 contr

[issue12641] Remove -mno-cygwin from distutils

Antoine Pitrou added the comment: 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/ -- nosy: +pitr

[issue12641] Remove -mno-cygwin from distutils

Changes by Éric Araujo : -- Removed message: http://bugs.python.org/msg196207 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue12641] Remove -mno-cygwin from distutils

Changes by PJ Eby : -- title: NewInterface -> Remove -mno-cygwin from distutils ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue12641] Remove -mno-cygwin from distutils

Changes by Éric Araujo : -- Removed message: http://bugs.python.org/msg195896 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue12641] Remove -mno-cygwin from distutils

Changes by Éric Araujo : -- title: Interface -> Remove -mno-cygwin from distutils ___ Python tracker ___ ___ Python-bugs-list mailing

[issue12641] Remove -mno-cygwin from distutils

Changes by Renato Silva : -- nosy: -renatosilva ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue12641] Remove -mno-cygwin from distutils

Changes by STINNER Victor : -- title: Test -> Remove -mno-cygwin from distutils ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue12641] Remove -mno-cygwin from distutils

Changes by Christian Heimes : -- title: Test -> Remove -mno-cygwin from distutils ___ Python tracker ___ ___ Python-bugs-list mailing

[issue12641] Remove -mno-cygwin from distutils

Changes by Charles-François Natali : -- title: Test -> Remove -mno-cygwin from distutils ___ Python tracker ___ ___ Python-bugs-list m

[issue12641] Remove -mno-cygwin from distutils

Changes by vengefulgash45 : Added file: http://bugs.python.org/file31406/test1.html ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: 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#

[issue12641] Remove -mno-cygwin from distutils

Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12641] Remove -mno-cygwin from distutils

Geert Jansen added the comment: *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

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: 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

[issue12641] Remove -mno-cygwin from distutils

Changes by Roy Ivy III : -- nosy: +rivy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 9 July 2013 17:36, Éric Araujo 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 dist

[issue12641] Remove -mno-cygwin from distutils

Éric Araujo added the comment: Don’t forget that distutils is used during CPython’s build process to compile extension modules: subprocess may not be importable then. -- ___ Python tracker

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 9 July 2013 16:25, Christian Heimes wrote: > > The is_cygwingcc() function can be simplified a lot with > subprocess.check_output(). My initial thought was to do that but then I based it on _find_exe_version which for whatever reason uses Popen directly [1]

[issue12641] Remove -mno-cygwin from distutils

Christian Heimes added the comment: The is_cygwingcc() function can be simplified a lot with subprocess.check_output(). -- nosy: +christian.heimes ___ Python tracker ___ ___

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: I'm attaching one more patch "check_mno_cywin_py34.patch". This is my preferred patch for Python 3.4 (default). It fixes building with MinGW and removes all support for using Cygwin gcc with --compiler=mingw32. The user would see the following error message: '''

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 24 June 2013 12:53, Oscar Benjamin wrote: > 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". Correction: the patches are not quite identical as the p

[issue12641] Remove -mno-cygwin from distutils

Changes by Oscar Benjamin : Added file: http://bugs.python.org/file30683/test_mno_cygwin.tar.gz ___ Python tracker ___ ___ Python-bugs-list ma

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 24 June 2013 09:07, Marc-Andre Lemburg 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" fo

[issue12641] Remove -mno-cygwin from distutils

Marc-Andre Lemburg added the comment: On 24.06.2013 00:00, Jeffrey Armstrong wrote: > > Jeffrey Armstrong added the comment: > >> ...the fact that this issue has been open for almost 2 years is quite >> ridiculous. > > I thought that I'd add a little statistic for everyone that might put this

[issue12641] Remove -mno-cygwin from distutils

Jeffrey Armstrong added the comment: > ...the fact that this issue has been open for almost 2 years is quite > ridiculous. I thought that I'd add a little statistic for everyone that might put this bug into perspective. Since this bug was opened, the MinGW installer has been downloaded about

[issue12641] Remove -mno-cygwin from distutils

frattaroli.nicolas added the comment: It's cool that you guys are discussing semantics of who said what and how, but that still doesn't fix this very simple issue that breaks compiling for everyone on Windows who uses MinGW. -mno-cygwin, was, as far as I know, only ever required to build from c

[issue12641] Remove -mno-cygwin from distutils

Renato Silva added the comment: > In context it should be clear that the statement "in gcc 4.x it > produces an error preventing build" refers to Cygwin's gcc and not > MinGW's. Which gcc are you referring to? If it refers to Cygwin only, sorry then. However, didn't folks said in MinGW thread

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: Oscar, 10x for info I know how to find information for this particular case . So you last post just confrim what I wrote before two years ( 2011-08-03 http://bugs.python.org/issue12641#msg141614 ) Go ahead and just remove flag. Roumen -- __

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 25 May 2013 04:43, Renato Silva wrote: > > Renato Silva added the comment: > > Hi Oscar! Sorry, I just meant to correct this information: "in gcc 4.x it > produces an error preventing build". Even if it doesn't do anything useful, > still GCC 4.4 does accep

[issue12641] Remove -mno-cygwin from distutils

Seppo Yli-Olli added the comment: ERRATA Misunderstood the meaning of ERRATA, please ignore my last post. Roumen Petrov wrote: > Where is written that compiler is gcc ? Yes this is current distutils > code but please review my set of patches I kinda like the using --target-help for finding out

[issue12641] Remove -mno-cygwin from distutils

Seppo Yli-Olli added the comment: Since Renata's ERRATA was unclear to whether or not this was *actually* removed (please point to a changeset if the option was removed): If the option is no longer required by Pidgin and that was the original reason to have it in the first, there's really no re

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: Oscar Benjamin wrote: > [SNIP]The option was only ever meaningful in cygwin's gcc 3.x and was > always an error in 4.x. May be . It seems to me flag was removed in GCC 4.5 . -- ___ Python tracker

[issue12641] Remove -mno-cygwin from distutils

Renato Silva added the comment: ERRATA. Where you see: "[1] clearly did not come to reality." Please read: "[0] clearly did not come to reality." [0] http://cygwin.com/ml/cygwin/2009-03/msg00802.html -- ___ Python tracker

[issue12641] Remove -mno-cygwin from distutils

Renato Silva added the comment: > MinGW has never "supported" the -mno-cygwin option. It has simply > tolerated it. The option never did anything useful and at some point > it became an error to even supply it. I'm not sure exactly when but > some time after 4.4 sounds reasonable to me. Hi Os

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: > Renato Silva added the comment: > > I must note that GCC 4.x *does* support -mno-cygwin, at least until 4.4, and at least the MinGW version. MinGW has never "supported" the -mno-cygwin option. It has simply tolerated it. The option never did anything useful an

[issue12641] Remove -mno-cygwin from distutils

Renato Silva added the comment: I must note that GCC 4.x *does* support -mno-cygwin, at least until 4.4, and at least the MinGW version. I have used it myself for building Pidgin under Windows, which requires that option. See [1] where a Pidgin developer confirms that. [1] http://pidgin.im/pi

[issue12641] Remove -mno-cygwin from distutils

Paul Moore added the comment: On 23 May 2013 20:11, Roumen Petrov wrote: > > Is this approach acceptable? > It is not enough. > Support for compilers other than gcc (including cross-compilers) is a separate issue, and one which is much less likely to get accepted. --

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: Oscar Benjamin wrote: > Oscar Benjamin added the comment: > > I have written a function that can be used to determine if the gcc > that distutils will use is from Cygwin or MinGW: > > def is_cygwingcc(): > '''Try to determine if the gcc that would be used is

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: I have written a function that can be used to determine if the gcc that distutils will use is from Cygwin or MinGW: def is_cygwingcc(): '''Try to determine if the gcc that would be used is from cygwin.''' out = Popen(['gcc', '-dumpmachine'], shell=True,

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 22 May 2013 13:40, Oscar Benjamin wrote: > > However on further reflection I'm a little reluctant to force an error > if I can't *prove* that the setup is broken. After a little more reflection I realise that we could just do: if self.gcc_version < '4'

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: 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

[issue12641] Remove -mno-cygwin from distutils

Martin v. Löwis added the comment: 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

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: On 21 May 2013 17:21, Martin v. Löwis wrote: > > C: Users who have only cygwin gcc 4.x installed > > For those, the current setup will produce an error message, essentially > telling them that the need to fix something (specifically: edit distutils, > install

[issue12641] Remove -mno-cygwin from distutils

Martin v. Löwis added the comment: Oscar: I agree with your analysis, but it is incomplete. There is a group C: Users who have only cygwin gcc 4.x installed For those, the current setup will produce an error message, essentially telling them that the need to fix something (specifically: edit d

[issue12641] Remove -mno-cygwin from distutils

Pete Forman added the comment: Another +1 for Oscar. I've just done an install of Python 2.7.5 and had to hack cygwinccompiler.py again. I'm using mingw with gcc 4.6.2 on Windows 7. -- nosy: +Pete.Forman ___ Python tracker

[issue12641] Remove -mno-cygwin from distutils

Paul Moore added the comment: +1 for Oscar's proposed fix. It sounds like a sensible approach. -- ___ Python tracker ___ ___ Python-bu

[issue12641] Remove -mno-cygwin from distutils

Oscar Benjamin added the comment: I'd really like to get a resolution on this issue so I've tried to gather some more information about this problem by asking some questions in the mingw-users mailing list. The resulting thread can be found here: http://comments.gmane.org/gmane.comp.gnu.mingw.u

[issue12641] Remove -mno-cygwin from distutils

Changes by Paul Moore : -- nosy: +pmoore ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue12641] Remove -mno-cygwin from distutils

Changes by Jeffrey Armstrong : -- nosy: +Jeffrey.Armstrong ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue12641] Remove -mno-cygwin from distutils

Jon added the comment: Eric, I'm assuming you are the key decision maker for any fix. As I want to see this issue stay razor focused, where specifically do you need community help? Depending upon your needs, I can test on my win7 32bit notebook with official python 2.7.3. It also has arch 3.7.

[issue12641] Remove -mno-cygwin from distutils

Dan added the comment: There's an additional aspect. Even though I don't use Windows as a development platform, I care about being able to propose Python to clients as a cross-platform technology (instead of, say, Java). Having an essential piece of Python infrastructure fail miserably on Wind

[issue12641] Remove -mno-cygwin from distutils

Jon added the comment: [Eric] >> This is about mingw, which is the **main free software that builds >> executables on Windows**. You know, for when you don't want to require >> your users to install Visual Studio. > Let me state that I fully sympathize with people who use Windows and > still want

[issue12641] Remove -mno-cygwin from distutils

Éric Araujo added the comment: [Martin] Thanks for the message. My previous message actually quoted Dan, not you, so no apology is necessary. [Dan] > That's bull, Eric. Could you rephrase this? English is not my native language. > This is not about a corner case in cygwin. Oops I confused c

[issue12641] Remove -mno-cygwin from distutils

Dan added the comment: That's bull, Eric. This is not about a corner case in cygwin. This is about mingw, which is the **main free software that builds executables on Windows**. You know, for when you don't want to require your users to install Visual Studio. Additionally, both you and Matthi

[issue12641] Remove -mno-cygwin from distutils

Martin Fiers added the comment: Dear Eric, I never said that anyone of these volunteers is unresponsible/stupid/whatsoever. It was also never my intention to express myself in this way, so I apologize if you felt harmed in any way. I was just suprised that this issue exists for so long. And s

[issue12641] Remove -mno-cygwin from distutils

Éric Araujo added the comment: > I don't understand; so many people depend on it and yet an out-of-the-box > solution doesn't work. It is because of the combinations of some facts: - Python contributors are volunteers; - distutils is used a lot and quite brittle, which is a combination that mak

[issue12641] Remove -mno-cygwin from distutils

Dan added the comment: Nice partial work-around. I think it's quite clear that the decision makers for this bug have not been making rational decisions for a year and a half, so we can't really expect change. This being the open-source world, the only recourse is publicizing the issue (or is

[issue12641] Remove -mno-cygwin from distutils

Martin Fiers added the comment: This also affects our software. I agree with Dan (danmbox): I don't understand; so many people depend on it and yet an out-of-the-box solution doesn't work. I don't want to break the distutils package of our users because we use mingw. Within one Python script,

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: > Dan added the comment: > > Guys, this looks really bad and inconveniences a lot of users. You install > the latest MinGW and Distutils from their default location, try using them on > **anything that requires compilation**, and get the cryptic gcc -mno-cygwin

[issue12641] Remove -mno-cygwin from distutils

Dan added the comment: Guys, this looks really bad and inconveniences a lot of users. You install the latest MinGW and Distutils from their default location, try using them on **anything that requires compilation**, and get the cryptic gcc -mno-cygwin error (after having to edit the obscure di

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: Hi Matthias, This issue is only for windows. In scope autotool based builds compiler customization is used to 'transfer' some build settings (flags, options) to distutils. This include compiler set in make macro (variable) CC. Transfer is not complete but thi

[issue12641] Remove -mno-cygwin from distutils

Martin v. Löwis added the comment: doko: this issue is about Windows; autoconf is not being used here (plus the "correct" compiler would be MSC). -- ___ Python tracker ___ _

[issue12641] Remove -mno-cygwin from distutils

Matthias Klose added the comment: 2.7, 3.3 and 3.4 now have AC_CANONICAL_HOST. So the correct compiler should be picked up. please could somebody validate this? or are explicit --host and --build options required for configure? -- nosy: +doko ___ P

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: And optionally If someone disagree options m{no-}cygwin to be removed I would like to propose a patch '..check if cygwin/mingw... -m{no-}cygwin' to restore it for GCC before 4.6x. -- Added file: http://bugs.python.org/file29032/0001-MINGW-issue12641-c

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: Next step is to propose customization for cygwin&mingw compilers. -- keywords: +patch Added file: http://bugs.python.org/file29031/0001-MINGW-issue12641-customize-mingw-cygwin-compilers.patch ___ Python tracker

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: In scope of this issue I would like to propose following patch set. First step is remove checks for versions used in past millenium, i.e. to avoid checks for 15 year old binaries. -- Added file: http://bugs.python.org/file29030/issue12641-modernize_cygw

[issue12641] Remove -mno-cygwin from distutils

Changes by Jakub Wilk : -- nosy: +jwilk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue12641] Remove -mno-cygwin from distutils

Martin v. Löwis added the comment: Geert: Someone will have to provide a patch, else the issue will go nowhere. I will insist that the patch continues to support "older" gcc installations (from 2012), at least if implemented as a bug fix to older Python releases. -- __

[issue12641] Remove -mno-cygwin from distutils

Geert Jansen added the comment: *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 ex

[issue12641] Remove -mno-cygwin from distutils

Ruben Van Boxem added the comment: 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. -- __

[issue12641] Remove -mno-cygwin from distutils

Craig McQueen added the comment: 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.

[issue12641] Remove -mno-cygwin from distutils

Martin v. Löwis added the comment: The 64-bit compiler is actually called x86_64-w64-mingw32-gcc. -- ___ Python tracker ___ ___ Pyth

[issue12641] Remove -mno-cygwin from distutils

Martin v. Löwis added the comment: 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

[issue12641] Remove -mno-cygwin from distutils

Martin v. Löwis added the comment: 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). -- ___ Python tracker

[issue12641] Remove -mno-cygwin from distutils

Craig McQueen added the comment: 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 #15315. -- nosy: +cmcqueen1975 ___ Python tracker

[issue12641] Remove -mno-cygwin from distutils

Phillip J. Eby added the comment: 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

[issue12641] Remove -mno-cygwin from distutils

Changes by Reuben Garrett : -- nosy: +RubyTuesdayDONO ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue12641] Remove -mno-cygwin from distutils

Éric Araujo added the comment: > 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 doe

[issue12641] Remove -mno-cygwin from distutils

Seppo Yli-Olli added the comment: 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. -- nosy: +Seppo.Y

[issue12641] Remove -mno-cygwin from distutils

Changes by Santoso Wijaya : -- nosy: +santa4nt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue12641] Remove -mno-cygwin from distutils

Jon added the comment: 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 li

[issue12641] Remove -mno-cygwin from distutils

Éric Araujo added the comment: 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. BT

[issue12641] Remove -mno-cygwin from distutils

Roumen Petrov added the comment: it is save to remove -mno-cygwin from Mingw32CCompiler -- ___ Python tracker ___ ___ Python-bugs-li

[issue12641] Remove -mno-cygwin from distutils

Jon added the comment: 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? -- ___ Python tracke

[issue12641] Remove -mno-cygwin from distutils

Changes by Roumen Petrov : -- nosy: +rpetrov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue12641] Remove -mno-cygwin from distutils

Jon added the comment: >> 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

[issue12641] Remove -mno-cygwin from distutils

Éric Araujo added the comment: > 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

[issue12641] Remove -mno-cygwin from distutils

Jon added the comment: 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

[issue12641] Remove -mno-cygwin from distutils

Jon added the comment: 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%20B

  1   2   >