Re: MinGW compilation on Windows

[Charles Wilson <cwilson at ece dot gatech dot edu>]

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