Mail Archives: cygwin-apps/2001/04/24/19:20:25
On 22 Apr 2001, at 10:43, the Illustrious Robert Collins wrote:
> ----- Original Message -----
> From: "Paul Garceau" <pgarceau AT qwest DOT net>
> To: <cygwin AT cygwin DOT com>
> Sent: Sunday, April 22, 2001 6:51 AM
> Subject: Re: GCC -mno-cygwin vs mingw32-gcc cross environment.
> > I would agree with Chris...not to "deprecate", as Earnie states, but
> > to discourage the use of -mno-cygwin for anyone not familiar enough
> > with the differences between using -mno-cygwin vs not using -mno-
> > cygwin. There has been a *ell of a lot of work put in to getting
> > -mno-cygwin to work over the years. I don't believe that effort
> > should be wasted by eliminating (or "deprecating", as Earnie puts it)
> > the -mno-cygwin switch.
> > If there is a "true cross-compiler available", as an "option", such
> > things should be pre-installed with any cygwin distributions. Not
> > everyone uses autoconfig, nor does everyone need to. Autoconfig is a
> > "convenience", not a "requirement".
> > When it comes to building using the -mno-cygwin switch, I can see how
> > it would be "convenient" to not type the extra 11 characters or so.
> > Autoconfig, if it is as great as some say, should be capable of
> > choosing whether to use -mno-cygwin vs. a "true cross compiler".
> And configure will choose a cross compiler with the --target=TARGET
> switch. Asking autoconf scripts to assume that a cross compiler is
> present doesn't make sense.
Admittedly, I don't know a lot about autoconf. Only attempted to
install it under mingw a couple of times...suceeded, but also had Posix
subsystem turned on (NT4). When Posix subsystem wasn't on, autoconf
simply failed. Win98 doesn't have a Posix Subsystem.
> Important thing to remember: mingw and cygwin are *different* platforms.
Yes, but many people (typically not the developer types) confuse the
two...they think that if you are using the -mno-cygwin switch that you
are actually building a Cygwin app when in fact you are not.
Of course, with proper documentation (and the willingness on the part
of those who use -mno-cygwin to actually read that documentation) this
wouldn't be a problem...at least not for Cygwin...
However, when they do read the documenation (my god they can actually
read !!! -- feeling evil today <eg>) they suddenly realize that, "my oh
my! This is _not_ Cygwin!!" and then they go post questions about
Cygwin on the mingw-users mailing list asking questions about -mno-
cygwin that can only be answered within the context of Cygwin, not
Mingw..can we say "c-o-n-f-u-s-i-o-n, boys and girls...?" (yes...evil
Given the above...when I say branch, I am saying create a cvs branch
that adds i686-pc-mingw32-gcc as a subset of Cygwin when Cygwins -mno-
cygwin switch is used...
At the very least, those of us who know the differences will be able
to reply more quickly (yes, it is selfish..but, as they say, time is
money...and when development of Cygwin is done largely on a volunteer
basis, such a "branch" (may be the wrong word here) would create order
where chaos used to reign in terms of the -mno-cygwin switch.
> > Cygwin and cross-compilers are not the same thing and should not be
> > included in the same distribution/setup process. Again, ultimately,
> > is the developer who should choose, the casual end user who just
> > downloaded Cygwin because they wanted to build something like "Crystal
> > Space" using the -mno-cygwin switch should not be burdened with trying
> > to build a cross-compiler instead of simply running "make".
> Developers are the folk who are able to build a cross compiler - IMO end
> users should never have to do anything other than configure && make &&
> make install and edit a basic config file or run a post-install setup
And developers (at least I would hope so) would be willing to learn,
if they absolutely need to, how to build a cross-compiler instead of
using something that has been pre-installed (won't mention the massive
increase in questions related to cross-compilers on the Cygwin or Mingw
mailing lists)...the newbies, however, unless they really know what
they are doing, shouldn't be forced to deal with the concept of cross-
compilers...they are already confused as it is (old Unix hands, e.g.
starting to use Cygwin on their home desktop pc -- these folks know
what Unix is about, but they do not know how Cygwin integrates Unix-
like processes within the Win32api environment.
> > > So, are you proposing that you will maintain a i686-pc-mingw32-gcc
> > > Earnie? One problem is that this will mean keeping at least a
> > > version of binutils/ld, too, since ld has some builtin defaults that
> > > not be appropriate for mingw.
> > Thereby forcing added maintenance requirements on people who don't
> > really have the time to be dealing with such things, as it is.
> a) maintainers are much more efficient than every new crystal space user
> learning how to build a cross-compile-tool-chain. b) someone maintains
> -mno-cygwin now. And we get what, 1-2 questions a day on -mno-cygwin?
> > Ultimately, seems easier to enable autoconfig under Mingw, and let the
> > people download Mingw (from the appropriate site) minus the generic
> > binutils (ie those duplicated between cygwin and the cygwin with -mno-
> > cygwin enabled), as an optional "plugin" sort of thing to Cygwin
> > -mno-cygwin switch). Especially if they wish to build -mno-cygwin
> > based executables or libs.
> What's needed to enable configre scripts under mingw?
> autoconf requires
> a unix-like environment
You answered your own question...
> (I don't know the exact requirements, but sh is
> definately there.) Of course if someone wants to fully port ash or bash
> to mingw it might work better.
I suppose you could try using the sh that comes with Mingw, but it is
not intended, afaik, to be any sort of substitute for an actual Unix
shell...it is basically, and Earnie, please correct me on this, nothing
more than a stub which is required for certain posixy type calls.
I do know that autoconf can be run from the MS-DOS Command Prompt
after it's been installed (no Unix shell required) as long as it is
> It does step past the _minimalist_ goals
> though :[ I'm not a mingwer, and don't claim to know or understand -
> perhaps a mingw'er can comment here - would including autoconf && sh as
> a core part of mingw lineup with the mingw philosophy?
In simplest terms, no.
> > In terms of "ld"...well, there are obvious differences between the
> > cygwin "ld" and the "ld" which I would recommend when using the -mno-
> > cygwin switch.
> > Cross compiler, no, new cygwin branch...possibly...
> What sort of branch are you suggesting - The only suggestions I get out
> of your comments above are * a new LD * autoconf scripts running
> properly on mingw * don't alter cygwin.
Unfortunately this is not always true unless you are talking about
complete abstraction between the two tool sets. -mno-cygwin does not
provide that and in fact can not abstract itself from Cygwin...a new
Even so, since the Mingw tool set is already fully functional and
available from a different place (outside of what I mentioned above in
terms of a Cygwin "branch"), what's the point? Use Cygwin if you
really need autoconf. Develop and maintain support for autoconf if you
really need to use autoconf with Mingw.
> > Just my comments on the subject...
> > >
> > > cgf
> > Peace,
> > Paul G.
> > >
> > Nothing real can be threatened.
> > Nothing unreal exists.
> > --
> > Want to unsubscribe from this list?
> > Check out: http://cygwin.com/ml/#unsubscribe-simple
Nothing real can be threatened.
Nothing unreal exists.
- Raw text -