Re: [Mingw-w64-public] GCC's -mnocygwin option

> >>> In order to get Python distutils fixed here:
> >>> http://bugs.python.org/issue12641
> >>>
> >>> We need to know when the -mno-cygwin option was rendered
> >>> unnecessary. The documentation conflicts itself, as explained in
> >>> the bug report. The commit removing the option is at the GCC 4.4
> >>> timeframe, but the 4.6 documentation is the first place where it
> >>> is removed from the details section.
> >>>
> >>
> >> I think it was toward the Cygwin 1.7 release. They decided to use
> >> a true cross compiler to support windows so it was no longer
> >> necessary. Which version of GCC it was removed, I have no idea but
> >> the switch was a specs file entry anyway and could have been
> >> removed in the Cygwin release of GCC manually from the delivered
> >> specs file.
> >>
> >> Earnie
> >
> > thanks for the info.
> >
> > 1) assuming no custom spec file, are you saying that if nothing is
> > returned from running `gcc -dumpspecs | grep -i no-cygwin` then the
> > specific mingw gcc compiler doesn't use -mno-cygwin?
> >
> > 2) other than performing a configure-like test, is there a
> > quick-n-dirty way to determine whether using -mno-cygwin will cause
> > mingw gcc to error out? i'm concerned about the case where (1) would
> > return nothing (meaning -mno-cygwin is not used by the compiler) but
> > using the option would cause a failure due to option validation code
> > elsewhere in the code.
> >
> > 3) any caveats in (1) or (2) depending upon whether you're "building
> > for win on win" or cross compiling "for win on *nix"?
> >
> > 4) is the following a concern, or a red herring?
> >
> > C:\>strings c:\mingw-rvb\bin\dllwrap.exe | grep -in no-cygwin 159:
> > --mno-cygwin Create Mingw DLL
> >
> 
> This is also interesting:
> 
> $ gcc --version
> gcc.exe (GCC) 4.5.2
> Copyright (C) 2010 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ gcc -v --help 2>&1 | grep cygwin
>   -mcygwin                    Use the Cygwin interface
> 
> 
> Both looks like leftover cruft.
> 
> With the mingw.org 4.5.2 version -mno-cygwin doesn't cause an error
> doing a build.  I suppose that a m4 autoconf macro could be constructed
> to determine if it errors the build but seems like overkill.  Maybe just
> base it on supported GCC versions and code it in the Makefile.in file.
> 

interesting idea given how much code is out there with -mno-cygwin.

  http://codesearch.google.com/#search/&q=mno-cygwin&type=cs

i'm also trying to get enough background info on this one to create a fairly lightweight, python-only patch to the 2.7 codebase using something similar to the following

>>> import subprocess
>>> import re
>>> output = subprocess.check_output(['gcc', '-dumpspecs'])
>>> print re.search('no-cygwin', output)
None

and isolate the mods to one of these two classes

  http://hg.python.org/cpython/file/65c412586901/Lib/distutils/cygwinccompiler.py#l85
  http://hg.python.org/cpython/file/65c412586901/Lib/distutils/cygwinccompiler.py#l271

as i _think_ it may be more robust that `gcc --version` style checks.

do you see any problems with the `gcc -dumpspecs` idea or know of a more reliable way?


Jon

---
blog: http://jonforums.github.com/
twitter: @jonforums

"Anyone who can only think of one way to spell a word obviously lacks imagination." - Mark Twain