On May 23, 2013 8:41 PM, "Keith Marshall" <keithmarshall@users.sourceforge.net> wrote:
> On 23/05/13 17:57, Roumen Petrov wrote:
> >>     if dumpmachine ends with 'cygwin':
> >>        use -mno-cygwin>
> >
> > No . Above is not enough to detect whether -mno-cygwin is supported or not.
> No, but...
>    test gcc -mno-cygwin -c -xc /dev/null -o /dev/null
> ...is.  Combine that with a check for *cygwin* in the output from either
> config.guess, (or from gcc -dumpmachine, if you prefer -- it probably is
> simpler when you're already using a gcc options check anyway), and you
> have all the information you need to trigger an informative diagnostic,
> or as a basis from which to develop an effective cross-compiler solution.

I'm not trying to determine if gcc will accept -mno-cygwin. The problem is that Cygwin gcc without -mno-cygwin will do the wrong thing (create a binary that depends on cygwin.dll) or display confusing compilation errors. I want it to just give the appropriate 'stop using -mno-cygwin' error message so I intend to continue passing -mno-cygwin if it is a cygwin gcc.

I'm also not trying to develop a cross-compiler solution. I should be clear about the cause of this problem. When someone installs Python, distutils is installed with it. Distutils provides code to compile extension packages using the compilers available on the user's system. Users can supply config files or command line options to select the compiler that distutils will use. So when a user supplies --compiler=mingw32 disutils assumes that mingw gcc is on PATH and starts issuing commands to gcc.

At some point it was decided that --compiler=mingw32 could be used when cygwin gcc was on PATH. If -mno-cygwin is given by distutils then mingw will ignore it and cygwin gcc will create a non-cygwin binary. This was IMO a design mistake and it has ultimately resulted in the issue I am trying to fix. If the no-cygwin mode had initially been given its own entry point (e.g. --compiler=no-cygwin) then this issue would have been easily fixed two years ago or would never have occurred.

If support is added to distutils for cygwin's cross-compilers (unlikely IMO) then we can trivially avoid all of these problems by using a new entry point --compiler=cygwin-cross. However we must continue to support this unfortunate arrangement for --compiler=mingw32 for backwards compatibility (at least in already released Python versions).

Thanks for your help,