Mail Archives: cygwin-developers/2001/10/25/16:10:21
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
- Raw text -