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 X-Apparently-From: Message-ID: <3BD96000.7A76442B@yahoo.com> Date: Fri, 26 Oct 2001 09:07:12 -0400 From: Earnie Boyd Reply-To: CD List X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Charles Wilson CC: Andrew Begel , cygwin-developers AT Cygwin DOT Com, Dmitry Bely , xemacs-winnt AT xemacs DOT org Subject: Re: MinGW compilation on Windows References: <3BD875D5 DOT 2030501 AT ece DOT gatech DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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! ) > 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