This is the mail archive of the
mailing list for the Cygwin project.
Re: Potential problems with Cygwin GCC and -mno-cygwin switch
- From: "Soren Andersen" <soren_andersen at speedymail dot org>
- To: <cygwin at cygwin dot com>
- Date: Tue, 8 Jan 2002 17:29:14 -0500
- Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch
- Reply-to: soren_andersen at speedymail dot org
On 26 Dec 2001 at 20:33, Jon Leichter wrote:
> It's been a long time since I was active on this list. I have not used
> Cygwin for over a year, until recently. I see that Cygwin has been updated
> quite a bit since I last used it. It's very nice to see these new features.
Me too (well that made me popular right off the bat ;-)!
Seriously, I too spend longish times away from Cygwin and then i am always
surprised at how much has been accomplished when i return. In particular
I'd like to acknowledge the recent accomplishment of getting the whole
automake/autoconf thing to be a built-in part of Cygwin at last. Whew!
> I have a couple of issues to discuss about Cygwin GCC and it's MinGW
> Before I get started, I'd like to make an observation. The MinGW web site
> (http://www.mingw.org/mingwfaq.shtml#faq-usingwithcygwin) suggests that:
> 1) MinGW support in Cygwin GCC is flaky and buggy
> 2) MinGW support in Cygwin GCC will possibly be deprecated
I have a few observations to make about this myself, on a general note.
First off I am not trying to dis anyone involved in minGW. Some readers may
realize I have been posting messages regarding minGW for a long while; I
use minGW as well as I can. And try to contribute to it although I am not a
talented or educated C programmer.
Historically speaking, minGW is what must be (IMHO of course!) acknowledged
as a "parasitic" offshoot of "Cygwin-gnuwin32". That is -- and pls, all
readers, try not to react as if I had meant a very perjorative thing -- it
was a bit like the life-form known as mistletoe, which grows on a living
tree's branches, sinking its tissues into the host plant and drawing
sustainance from it, but is also a green plant on its own. Parasitic in a
semi-way. As time has passed minGW has tried in various ways to become
"self-hosting" -- very specific meaning to hackers, there, of course, but
also works in my metaphor here -- and moved away from complete reliance on
Cygwin and its bash environment and UNIX emulation. The way it has done
this has been a bit anarchical. Paul Sokolovsky has his "PW" scheme and
"Mikey" (if I recall right) has his approach, etc etc. In short, minGW has
been no where near as disciplined and organized as Cygwin. Lacking a single
corporate sponsor such as Cygwin has in RedHat, that shouldn't be too
This lack of sponsorship maybe is also part of the noted tendency for minGW
priciple persons to manifest some, uhh, let's say testiness. People who
pioneer new areas and sink huge amounts of personal time and effort into
tough problem-solving with minimal broad-based outside interest or support
sometimes become as a result a bit, uh, proprietary in their feelings about
the project to which they've dedicated themselves. This can involve also a
certain lack of balanced perspective, inability to grasp the perspectives
of newcomers or outsiders, and -- sorry -- arrogance in attitude,
sometimes. I've seen all this from certain people involved in minGW.
Overall, though, its an amazing thing that minGW even exists, and has
accomplished as much as it as.
One thing that is pretty clear to me is that there is no one person, aside
maybe from Mumit Khan, who can legitimately present him/herself as
"speaking for" minGW. I think that needs to be acknowledged if there's been
some impression that "minGW is criticizing cygwin". minGW is first and
foremost a free-for-all, a collaborative exercize that moves forward by
fits and starts. In any such assemblage of personalities there are bound to
be some outspoken individuals (no sh__:-) who express frustrations they are
having in a way that isn't echoed by more silent participants.
> 3) a better solution for MinGW binaries from a Cygwin environment
> is to install MinGW GCC over Cygwin
I personally keep the two absolutely separate in their own filesystem
trees. TTBOMK the win32API files in Cygwin lag a little behind those on
minGW -- maybe somebody can correct me on this -- and I prefer, lacking
expertise on many things, to try to maximize my good results by not mixing
the two to unknown side-effects.
> From what I've seen, it looks like MinGW support in Cygwin GCC is up-to-date
> and better than ever before. So, I have no idea what the MinGW web site is
> referring to. Does anyone from Cygwin agree that MinGW support will be
I hope not. I am going to be studying the responses to this msg for the
next several days in an attempt to understand WHAT they are talking about
(argh). I gather that it is mostly about linker scripts which i have never
understood very well (and to tell the truth, hope i don't have to).
> I, personally, find it much better to build MinGW binaries with Cygwin GCC.
> In my work, I often build projects with shell scripts. Using the Cygwin bash
> shell is the easiest (if not, the only) way to interpret these shell
> scripts. Many times, shell scripts create symbolic links and specify them to
> compiler tools as parameters. Only a Cygwin binary can interpret these
> symbolic links. If a symbolic link were specified as a parameter to a MinGW
> compiler tool, it would fail. Thus, I fail to see how MinGW GCC over Cygwin
> is a better solution than MinGW support provided by Cygwin GCC.
That makes sense to me.
> While I do think Cygwin GCC currently does a great job of supporting MinGW,
> I do have a few issues with it:
Hopefully this can all get resolved peacefully and harmoniously. The one
thing I hope is that the
collective attitudes at minGW never get to the point where people "over
there" (some of whom are also "people over here") have forgotten the debt
of appreciation they owe to cygwin, for being the historical predecessor
and "host" that allowed them to come into existence, if for nothing else.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html