Re: MinGW compilation on Windows

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

Andrew Begel wrote:

 > On Thursday, October 25, 2001, at 12:49  PM, Charles Wilson wrote:
 >>> (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?
 >>
 >
 > If your app/DLL links with cygwin1.dll (at least as of cygwin's dll  v1.1)
 >  you can't link with Microsoft's MSVCRT library. Which means that  you
 >  can't link with any DLL (vendor-provided, let's say an IBM ViaVoice  DLL)
 >  that itself is linked with MSVCRT. I don't care about standalone  apps;
 >  I use Cygwin's shells and make program and mount and all that  stuff.
 >  But for applications that I build that have to play nicely (read  link
 >  dynamically with) other Windows applications/DLLs, it's necessary  to
 >  compile without Cygwin.


Ahhhhh....I thought you were referring to application interoperability --
something that works pretty well, but still has a few hiccups; details help
us fix those.  Dynamic linking interoperability is a whole 'nother can of
worms, indeed -- and there's little we can do about that.

There was some discussion a few days ago (on the cygwin list) about a 
"cygwin-compat" library that snoops for the registry entries for cygwin's 
mount points, and provides path conversion capabilities *without* linking 
the cgywin1.dll itself.  This idea would help interoperability, but so far 
we haven't seen the implementation.  Anyway, this is a different topic for 
a different thread.

 >> 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.
 >>
 >
 > I don't assume to know what's going on in the mind's of Mingw's  developers
 >  re: future development. If the Cygwin gcc -mno-cygwin and the  Mingw
 > native gcc merge into one app, that's fine.

Oh, geez - I didn't say THAT!  (You're gonna get me in trouble! <g>)

 > As long as both  projects
 > agree on where to put MinGW's headers, I'll be happy. Right  now,
 > they're in two different places. MinGW  puts them in   c:\mingw\include.
 >  Cygwin puts them in /usr/include/mingw (or in Windows  paths:
 > c:\cygwin\usr\include\mingw).

Hmm...didn't know that.

 >>> 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. :-)
 >>
 >
 > That's not the problem. MinGW doesn't pretend to do more than it
 > advertises; simply a gcc that accepts both windows and unix style paths,

unix-style -> C:\foo\bar = c:/foo/bar ?  That's *not* unix style.  It's 
still a multiple-root colon-delimited pathspec.  AFAIK mingw's gcc has no 
knowledge of any cygwin-style mount system (a system which gives cygwin a 
true unix-style single-root pathspec (and no colons)).

 > and produces executables that link with Microsoft libraries rather than
 > cygwin1.dll. The build environment that MS provides is pretty crappy.
 > I'm porting Linux apps, and I like cygwin's unixy side for development.
 > I just need the apps to be compiled without cygwin. (Oh, did I mention
 > these were C++ apps that I'm making? Those require MinGW's g++ compiler,
 > unless cygwin is now distribution (again) the C++ support
 > libraries/headers for MinGW?)

Not yet.  Earnie (maintainer for cygwin's mingw-runtime and w32api 
packages) has promised to provide the required g++ libs, but hasn't yet.


 >> 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.
 >
 >
 > Yes, I want a), but I want to use MinGW's gcc compiler, not Cygwin's
 > cross compiler.

You mean cygwin's "gcc -mno-cygwin"?  That's not a real cross-compiler, 
call it a "poor-man's cross".

 > Since the include directories are different (see above)
 > I need to distinguish between the two at some point in the
 > configure/compile process....

What if mingw (or a mingw-aware cgywin person) provided a TRUE 
cygwin-hosted, mingw-targetted cross compiler?  Such a compiler would 
natrually look in /usr/include/mingw and /usr/lib/mingw (or even 
/usr/i686-pc-mingw/include &tc), so that part is okay.

Then the problem boils down to insuring that the cygwin mingw-runtime, 
w32api, and "mingw-cross"(?) packages are kept up-to-date -- either by 
mingw people or by mingw-aware cygwin people.  Ideally, these packages 
would come from the same source tree as the "native" mingw tools 
(currently, Earnie keeps our w32api and mingw-runtime in sync pretty well, 
I think).

That's (keeping packages current) a much easier problem to solve than some 
of the other ideas I've seen floating around...

--Chuck