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