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

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

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

  Opinionatedly Yours,
     Soren Andersen

Unsubscribe info:
Bug reporting:

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