This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: Compiling apps to Mingw32 with cygwin
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- To: "Jon Leichter" <jon at symas dot com>,<earnie_boyd at yahoo dot com>
- Cc: <hschwentner at yahoo dot com>,<cygwin at cygwin dot com>
- Date: Fri, 11 Jan 2002 11:28:00 +1100
- Subject: Re: Compiling apps to Mingw32 with cygwin
- References: <DLEBJKNCNLJEDKMKICHGCENLCBAA.jon@symas.com>
===
----- Original Message -----
From: "Jon Leichter" <jon@symas.com>
> I still don't understand why I'd want to symlink the binutils
binaries. I
> WANT the Cygwin binutils. They don't generate object code; they
operate on
> it. The Cygwin binutils do a fine job (as Cygwin binaries) operating
on
> MinGW binaries. I've never had a problem.
Because when autoconf is cross compiling (that is, when _host_!=_build_)
it looks for compilers and binutils utilities named with a prefix of the
_target_ they where built for.
IOW when you configure foo
with --build=i686-pc-cygwin --host=i686-pc-mingw32
autoconf looks for gcc and binutils created via:
configure --build=wherever --host=i686-pc-cygwin --target=i686-pc-mingw3
2
(note that the gcc/binutil HOST is == to the foo BUILD). Those
gc+binutils files get named with a prefix == the target they arebuilt
for (that is i686-pc-mingw32).
Now the cygwin standard gcc and binutils (which are prefixed with
i686-pc-cygwin can happily generate mingw32 code, so the symlink
i686-pc-mingw32 lets autoconf find what it expects.
Rob
--
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/