Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <054701c19a36$d3d8b230$0200a8c0@lifelesswks> From: "Robert Collins" To: "Jon Leichter" , Cc: , References: 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 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 11 Jan 2002 00:27:59.0747 (UTC) FILETIME=[D2BB0D30:01C19A36] === ----- Original Message ----- From: "Jon Leichter" > 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/