Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Message-ID: <054701c19a36$d3d8b230$0200a8c0@lifelesswks>
From: "Robert Collins" <robert.collins@itdomain.com.au>
To: "Jon Leichter" <jon@symas.com>, <earnie_boyd@yahoo.com>
Cc: <hschwentner@yahoo.com>, <cygwin@cygwin.com>
References: <DLEBJKNCNLJEDKMKICHGCENLCBAA.jon@symas.com>
Subject: Re: Compiling apps to Mingw32 with cygwin
Date: Fri, 11 Jan 2002 11:28:00 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


===
----- 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/