Mail Archives: cygwin/2002/01/10/21:12:20
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:robert DOT collins AT itdomain DOT com DOT au]
> Sent: Thursday, January 10, 2002 5:52 PM
> To: Jon Leichter
> Cc: cygwin AT cygwin DOT com
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> ----- Original Message -----
> From: "Jon Leichter" <jon AT symas DOT com>
>
> > 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/
- Raw text -