Mail Archives: cygwin/2002/01/09/13:38:31
> Subject: Re: Potential problems with Cygwin GCC and -mno-cygwin switch
> Date: Tue, 8 Jan 2002 17:29:14 -0500
> From: "Soren Andersen" <soren_andersen AT speedymail DOT org>
> To: <cygwin AT cygwin DOT com>
>
> 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
> > (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'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
^^^^^^^^^^^
pejorative
> -- 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 www.mingw.org and you've flamed it's
originator'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
themselves.
> 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
scripts".
> > 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,
Earnie.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -