ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/04/24/19:20:25

Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Delivered-To: fixup-cygwin-apps AT cygwin DOT com@fixme
From: "Paul Garceau" <pgarceau AT qwest DOT net>
Organization: New Dawn Productions
To: cygwin-apps AT cygwin DOT com
Date: Tue, 24 Apr 2001 16:17:47 -0700
Subject: Re: GCC -mno-cygwin vs mingw32-gcc cross environment.
Reply-to: Paul Garceau <pgarceau AT qwest DOT net>
Message-ID: <3AE5A72B.27311.BA042D@localhost>
In-reply-to: <014f01c0cac5$3789f510$0200a8c0@lifelesswks>
X-mailer: Pegasus Mail for Win32 (v3.12c)

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 
mood again...<eg>)

	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,
> it
> > 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
> script.

	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
> port,
> > > Earnie?  One problem is that this will mean keeping at least a
> separate
> > > version of binutils/ld, too, since ld has some builtin defaults that
> may
> > > 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
> (using
> > -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 
configured properly.

> 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 
"branch" might.
	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.


		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.

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019