Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Message-ID: <3BD86CB3.3040809@ece.gatech.edu> Date: Thu, 25 Oct 2001 15:49:07 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Andrew Begel , cygwin-developers AT cygwin DOT com CC: Dmitry Bely , xemacs-winnt AT xemacs DOT org Subject: Re: MinGW compilation on Windows References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A voice from the cygwin side of things...[crossposted to cygwin-developers] Andrew Begel wrote: > On Thursday, October 25, 2001, at 03:17 AM, Dmitry Bely wrote: > >> >> To confure XEmacs under NT you anyway need bash shell from Cygwin >> distribution. So you will need both Cygwin and Mingw tools. Why then not >> to exclude the latter and use Cygwin with -mno-cygwin switch? I don't see >> why it is worse than the native mingw gcc. >> > > The native MinGW tools don't require any switches, are updated more > frequently than the Cygwin cross-compilation tools, deal with > Windows-style pathnames a little more simply, and come with all the nice > features that make living without the cygwin1.dll much simpler. (The > cygwin dll is detrimental to the health of Windows apps that want to > play well with other Windows DLLs). Evidence? Specifics? Bug reports? Patches? Come on, please don't denigrate our project with vague generalities. > Given that there are two equivalent compilers (and IMHO, Cygnus should > stop distributing MinGW utilities and just refer people to > www.mingw.org), Except for a few minor issues #1. several cygwin tools must be able to run sans-cygwin1.dll (setup.exe, for instance). Therefore, we need "gcc -mno-cygwin" regardless of whether you use it for Xemacs or other apps. #2. We *don't* distribute mingw utilities (executables). The only "mingw" packages we distribute are "mingw-runtime" which includes header files, a few import libs, and the mingwm10.dll, and "w32api" which contains more header files and import libraries. Both packages are maintained by an active mingw developer who also happens to be a cygwin developer -- Earnie Boyd. #3. It's my belief that we'd prefer a cygwin-hosted mingw cross compiler, and relegate -mno-cygwin to the background (still necessary for minor tasks, but not "out in front" as a "mingw-lite".) #4. did you know that Earnie just forked cygwin and creaed a "cygwin-lite"-hosted mingw toolchain apparently at the request of the mingw developers? (The cgywin folks were somewhat suprised by THAT development!) Which is it -- mingw should stand alone as a fully native item (even though configure scripts and such don't seem to work very well without POSIX support), or should mingw assimilate into the cgywin (cygwin-lite) collective? It seems that even the mingw developers can't decide. > we do need a way to discriminate between them at least > at configure time, so that we can get the include paths that rely on > mingw include files to be correctly specified for both compilers. Waitaminute. You're assuming that you can actually RUN a #!/bin/sh configure script, aren't you? doesn't that presuppose a sh shell? Which (probably) runs on top of cygwin1.dll (or uwin or pw)? Or are you using a "native" sh? But configure scripts usually call other executables, like "uname" and "sed" and "awk" -- do you have native ports of those, too, or are they "cygwinized"? IMO, the real problem with mingw is that it wants to pretend it's unix (posix shell, configure scripts, etc) -- but build apps that aren't unix (ie. don't rely on cygwin1.dll or uwin.dll or whatnot for POSIX capabilities). It seems to me that in that scenario, mingw IS a cross compiler -- hosted on a POSIX system (cygwin, uwin, whatever) but targeted for native windows. Naturally, you could use mingw in what I call "MSVC-mode" -- xemacs.mak style makefiles, with C:\foo\bar style paths, use cmd.exe as your shell (sic), -- but then you have no "./configure". (And of course, if you put a unixy path into your "xemacs-mingw.mak"/config.inc instead of a proper windowsy path, that's your fault. :-) > I'm in the middle of asking the MinGW people how to reliably tell the > difference between the two, and when they do, I'll get back to you. Why? again, you're running a configure style script which obviously is (incorrectly) supplying unixy paths -- but then you pass those paths to the "native" mingw which doesn't understand them. It seems that what you want is (a) unixy configure + posix-hosted mingw cross compiler, OR (b) NO unixy configure (e.g. do it the "xemacs.mak/MSVC" way) + native mingw compiler. Granted, "gcc -mno-cygwin" is a poor substitute for a full-fledged cygwin-hosted mingw-targetted cross compiler. But it's *mostly* there. Anyway, it's funny this comes up today. There's a discussion of these issues going on right now (both onlist and off) prompted by the recent cygwin/cygwin-lite fork. --Chuck