This is the mail archive of the
mailing list for the Cygwin project.
Re: GCC -mno-cygwin vs mingw32-gcc cross environment.
- To: "Paul Garceau" <pgarceau at qwest dot net>,<cygwin-apps at cygwin dot com>
- Subject: Re: GCC -mno-cygwin vs mingw32-gcc cross environment.
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Date: Wed, 25 Apr 2001 09:43:59 +1000
- References: <3AE5A72B.27311.BA042D@localhost>
----- Original Message -----
From: "Paul Garceau" <firstname.lastname@example.org>
Sent: Wednesday, April 25, 2001 9:17 AM
Subject: Re: GCC -mno-cygwin vs mingw32-gcc cross environment.
> On 22 Apr 2001, at 10:43, the Illustrious Robert Collins wrote:
> > ----- Original Message -----
> > From: "Paul Garceau" <email@example.com>
> > >
> > 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
> subsystem turned on (NT4). When Posix subsystem wasn't on, autoconf
> simply failed. Win98 doesn't have a Posix Subsystem.
It might pay to find out a little more as it's one of the points in your
discussion. (see below)
> > Important thing to remember: mingw and cygwin are *different*
> 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.
non-developers only build apps for two reasons: they've got a source
dist they want to use, or they want to become developer types.
for source dist reasons this whole discussion it moot: It's the
packagers responsibility to document what is needed, and do it clearly.
Changing things will actually increase end user confusion.
for new developers, We are choosing what type of question, but one
question will still get asked:
I want to do foo - do I use mingw or cygwin?
> 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...
I don't see how that will help. CVS branchs allow for concurrent
development. I.E. If I ask chris nicely he may give me a new branch on
cvs.sources.redhat.com for me to really push the pthread code ahead -
and it would only be needed if there where 3 or 4 folk all working on
the same project but we didn't want to break CVS HEAD at all.
Please explain a little more clearly for me :]
> 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.
I don't see how we will be able to tell whats going on more easily:
Either the end user is passing -mno-cygwin or they aren't. At the moment
that's pretty clear cut. Having to ask
what gcc version, what gcc-mingw version is two questions, not one.
> 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
> 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.
Again, it really doesn't matter: If the unix-old-hand is trying to run a
source dist then they will follow the packagers instructions. If they
*choose* to say "I don't want to link with cygwin" so I'll
try -mno-cygwin they are becoming developers. A cross-compiler won't
make those packages run. Those questions will still arise.
So we're back to the developers.
> > What's needed to enable configre scripts under mingw?
> > autoconf requires
> > a unix-like environment
> You answered your own question...
Uhmm it was in response to your comment about crystal space and mingw.
Check the history.
> 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,
> more than a stub which is required for certain posixy type calls.
> > 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
> > a core part of mingw lineup with the mingw philosophy?
> In simplest terms, no.
here's my point:
predicate 1) mingw doesn't support or want autoconf for it's packages.
=> little or no mingw source dists will use configure
So using your crystal space example, the users are no better off. If
they download the wrong environment (cygwin) the mingw instructions
won't work. And vice versa.
> > > In terms of "ld"...well, there are obvious differences between the
> > > cygwin "ld" and the "ld" which I would recommend when using
> > > cygwin switch.
> > >
> > > Cross compiler, no, new cygwin branch...possibly...
> > What sort of branch are you suggesting - The only suggestions I get
> > 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
> "branch" might.
Paul, I'm not suggesting anything: I'm trying to understand what _you_
are suggesting. Please read my sentences fully!
> 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
> really need to use autoconf with Mingw.
I though you suggested two emails back that crystal space et al should
use autoconf. Have you reversed your position?
> Paul G.
> > Rob
> > > 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.