Re: MinGW compilation on Windows

[Earnie Boyd <earnie_boyd at yahoo dot com>]

I'm not sure why Chuck chose the Cygwin-Developers list for his
responses but since he did I'll leave them here and apologize.

Charles Wilson wrote:
> 
> 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.
> 

It isn't guaranteed that a gcc object will link together with an MSVC
object, regardless of which gcc compiler you used.  It's worse with C++
objects.  


>  >> 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>)
> 

MinGW's real mission is the runtime glue.  Everything else is a
dependent on that.

>  > 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.
> 

IIRC, the mingw-runtime package top directories are include/, lib/ and
bin/.  The MinGW package is `configure --prefix=/mingw' for obvious
reasons.

>  >>> 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)).
> 

You forgot to mention the ';' as the path delimiter in the PATH
variable.  Chuck, there are "native" shells, zsh and ksh that have been
ported similarly by Amol (I forget his last name).  There are also
"native" versions of common unix tools that can be executed in them. 
The "native" version of make actually searches for "/bin/sh" to see if
it can be found.  The problem with using these stems from the nonposix
that remains in the environment.

>  > 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.
> 

I've just not had a real desire.  I've looked at it, Chris started to
add the libraries to the winsup/mingw CVS and I objected so he removed
it.  Danny Smith has pulled the C++ specific libraries and ziped them up
into a package on his website.  That package isn't in the right format
for Cygwin distribution.  Visit the www.mingw.org site for more details.

>  >> 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".
> 

Agreed, but I don't thing this is a bad idea.  I think the name of this
switch is misnomered.  One of the when I get round tuits I need to grab
is deprecating that to -mmingw.

>  > 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.
> 

This doesn't require a mingw or a mingw-aware cygwin person.  Anyone
could create the cross.  Hmm... config.sub returns i386-pc-mingw32 so
that would be i386-pc-mingw32 unless you modified config.sub.

> 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).
> 

Thanks.  Yes, I try to keep the CVS synchronized.  The package
distribution is merely configuring for the correct target and uploading
to the correct servers.

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

Floating ideas is always easy, implementing them takes guts.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com