Message-ID: <45C14DE8.1070406@cwilson.fastmail.fm>
Date: Wed, 31 Jan 2007 21:18:16 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Eliminating -mno-cygwin from gcc?
References: <20070131131337 DOT GA17256 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20070131131337.GA17256@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

[I haven't read the whole thread yet, so I reserve the right to revise 
and extend.  Also, to say something somebody else already did, or 
otherwise generally make an idiot of myself]

Christopher Faylor wrote:
> How about if we eliminate -mno-cygwin from future releases and either
> provide our own mingw cross-tools or wrap the offerings from mingw.org?
> This would mean that instead of saying 'gcc -mno-cygwin', you'd say:
> 'i686-mingw-gcc' which would, I know, make a few computers spontaneously
> self-destruct however, I really don't think that the -mno-cygwin belongs
> in gcc.  No other port of gcc has anything like this.

I agree in principle -- and would prefer a cygwin-hosted cross-compiler, 
rather than using the mingw offerings, for two reasons which I will get 
to later.

But first, the most important question: what is Dave Korn's opinion?  As 
the current GCC maintainer for cygwin, a change like this would fall 
most heavily on him [*] The number of packages Dave releases wouldn't 
change, but there will be inevitable ripples that he'd have to deal with.

[*] And on the maintainers of the binutils package (cgf? Corinna?), the 
mingw-runtime package, the w32api package, and the 
mingw-zlib,mingw-bzip2 packages. (The last two are mine, and are 
no-brainers. But the other three will also get some ripple from this 
proposal)

My reasons for preferring a cygwinH-mingwT cross compiler:

[1] the mingw offerings are not always in sync with cygwin version-wise. 
  Presently they are on:
     Current=3.4.2,
     Prev=3.2.3, 3.3.1, 2.95.3
     Candidate=3.4.5
     Proposed=3.4.5+DW2
and not all have the same set of frontends. Which one would we provide 
(and note that 3.4.4 -- our current cygwin gcc version -- is not one of 
the choices)?

[2] The MinGW gcc does not understand unix paths, only dos paths. This 
will lead to unexpected un-cygwin-ness when using the compiler, 
expecially when running configure scripts, etc.

MinGW works around this with their MSYS fork of cygwin, which 
auto-converts stuff on the command line to/from dos format when the 
target program is non-MSYS-linked (but then there are those corner 
cases: Win32-style options (/Fo:bob), cmdline args with embedded paths 
(-I/usr/mingw), etc.

I don't think we want to imitate that in cygwin.  But it's still better 
if we can pass unix-style paths to the "-mno-cygwin" compiler.  This 
argues for a cygwin-hosted true cross compiler, rather than using the 
native-win32-hosted version from MinGW.

But let me re-iterate: the opinion of Dave and those other maintainers 
are the controlling one, IMO. (Oh, and does Dave build existing gcc 
releases natively, or on linux?  If the latter, then the mingw compiler 
will be a three-way: linuxB-cygwinH-mingwT...)

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/