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: List-Archive: List-Post: List-Help: , 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" 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 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" > To: > 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 ) 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...) 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. Peace, 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.