Thus... returning to the ORIGINAL topic of this thread... I had recommended the following to the OP:
$ env CC=mgcc ./configure --host=i686-pc-mingw32 My new understanding of switches gives me new perspective. 'build' and 'target' will pickup the value of 'host'. In this context, you're telling configure that the host == build == MinGW. I've said before that MinGW in Cygwin is a loose cross-compile. So, it seems to me that this configuration is ok, especially since 'host' binaries CAN successfully run in the 'build' environment. It seems to me that my original solution is suitable whether or not one's configure script was written "properly" and was built with the latest autoconf. We agreed that as of today that 'build', if not specified, gets the value of 'host'. Even if this were to change, i.e. 'build' gets checked for automatically, my solution STILL works. In this case, it would be a cross compile, but it should still work. This leads one to draw the following conclusions: - If one uses the --host, --build, and --target switches properly, he is not guaranteed that the configure script will work correctly. It will only work correctly IFF an up-to-date autoconf generated the script AND the switches were utilized correctly in configure.in. - If one uses my method posted above, it will work most (if not all) of the time. So, it may not be "proper", but it WILL work. This whole thread went off on a tangent suggesting that my solution was wrong. So tell me. If my solution works more often than the "proper" one, how is it wrong? Jon > -----Original Message----- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 10, 2002 5:52 PM > To: Jon Leichter > Cc: [EMAIL PROTECTED] > Subject: Re: Compiling apps to Mingw32 with cygwin > > ----- Original Message ----- > From: "Jon Leichter" <[EMAIL PROTECTED]> > > > AC_CHECK_TOOL checks for tools with a ${host} prefix. AC_CHECK_PROG > does > > not. > > > > In my opinion, this serves as another example that one cannot count on > a > > configure script being up-to-date. > > Ouchies. I agree - yet another reason for cygwin ports to be updated by > the maintainer :}. > > Rov > > > -- 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/