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: <3BD875D5.2030501@ece.gatech.edu> Date: Thu, 25 Oct 2001 16:28:05 -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 CC: cygwin-developers AT cygwin DOT com, 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 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! ) > 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