This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Potential problems with Cygwin GCC and -mno-cygwin switch

> Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch
> Date: Tue, 8 Jan 2002 17:29:14 -0500
> From: "Soren Andersen" <>
> To: <>
> On 26 Dec 2001 at 20:33, Jon Leichter wrote:
> > I have a couple of issues to discuss about Cygwin GCC and it's MinGW
> > support.
> >
> > Before I get started, I'd like to make an observation. The MinGW web site
> > ( suggests that:
> >
> >  1) MinGW support in Cygwin GCC is flaky and buggy
> >  2) MinGW support in Cygwin GCC will possibly be deprecated

I'll admit that these statements need to be restated.  I don't remember
if I or someone else made the statements but, these are flamitory and I
apologize.  Cygwin is a great tool, a lot of work has gone into it and
continues to go into it on a daily basis.  I certainly use it daily, I'd
be lost without it.  I've even contributed to Cygwin's GCC -mno-cygwin
source so please don't take ill intent at these statements.

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

All contributions are gratefully reviewed.

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

MinGW's history is documented at and you've flamed it's

> This lack of sponsorship maybe is also part of the noted tendency for minGW
> priciple persons to manifest some, uhh, let's say testiness. 

You give no reference to prove what you say or to allow anyone to defend

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

I don't know of whom you speak.

> 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 I just did, and have.

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

Criticism, none intentional.  Observation of problems mixing the
environments is what's trying to be portrayed.  Observation about what's
been said about -mno-cygwin in the past in this list is what's trying to
be portrayed.

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

I'll correct you on this.  I release to both Cygwin and MinGW on the
same day from the same set of sources new versions of w32api.  There may
be a few weeks of differences in the CVS versions between MinGW and
Cygwin but those get merged eventually.

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

Be sure you research all the archives in all the lists including the
MinGW list.  I don't think it has to do anything at all with "linker

> > 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:
> {snip details}
> 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.

Hopefully, this post has help toward that,

Do You Yahoo!?
Get your free address at

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]