From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6984 invoked by alias); 10 Jan 2002 22:29:21 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 6957 invoked from network); 10 Jan 2002 22:29:20 -0000 Received: from unknown (HELO itdomain003.itdomain.net.au) (203.63.157.208) by sources.redhat.com with SMTP; 10 Jan 2002 22:29:20 -0000 Received: from lifelesswks ([203.51.0.200]) by itdomain003.itdomain.net.au with Microsoft SMTPSVC(5.0.2195.3779); Fri, 11 Jan 2002 09:27:56 +1100 Message-ID: <04b801c19a26$0e699600$0200a8c0@lifelesswks> From: "Robert Collins" To: "Jon Leichter" Cc: , References: Subject: Re: Compiling apps to Mingw32 with cygwin Date: Thu, 10 Jan 2002 14:29:00 -0000 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: 10 Jan 2002 22:27:56.0755 (UTC) FILETIME=[0D69B230:01C19A26] X-SW-Source: 2002-01/txt/msg00679.txt.bz2 ----- Original Message ----- From: "Jon Leichter" > > No. Specify --host. The meaning is clearly documented in the autoconf > > documentation. > > For clarity: > > build - what OS the compilation is running on.. > > host - what OS the binaries created should run on. > > target - what OS the binaries created should target their output to. > > Actually, I'm a little unclear. Are you saying that 'target' is for binaries > that you build, which in themselves, generate other binaries? Would an > example of this be GCC? Yes. The way they are used is kinda cool. Imagine that you've got a new platform (say wince). It's got no gcc at the moment, and the c compiler you've got for it is brain-dead (can't host a two-stage gcc build). You do have a C library that should build for it. What you do is: build gcc+binutils with --build=here --host=here --target=wince and then build the C library for that platform. Place those libraries in an appropriate search location (ie /usr/local/lib/wince :}) then you build gcc+binutils with --build=here --host=wince --target=wince and then you copy the resulting binaries to the target platform, and finally can build gcc as a native 3 step boot strap, to ensure everything is ok. i.e. (for completeness) build gcc+binutils with --build=wince --host=wince --target=wince > Would I still need to "properly" specify --target if > I wasn't building binaries that generated binaries? Would you then say that > the following is the appropriate set of switches for Cygwin-GCC to produce > MinGW binaries: Target can be safely skipped if you know for sure that the package does not create platform specific output. I'm not saying 'binaries' here because there are other forms of platform specific output that may exist. > --build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32 Yes, that should work. GCC will look for a i686-pc-mingw32 cross compiler. > Can I leave out the --build switch? Will it get automatically resolved? Or Thats what I said :}. I was wrong (I've just rechecked). In theory I'm right, but for backward compatability, if you specify host, but not build, then build is set to host. This is (obviously) wrong and will eventually get removed. For now specify both build and host explicitly. (which is a bummer for cross- scripts (because the user must then know what build is, or the script must duplicate what config.guess and config.sub do.). > does that ALSO depend on how well configure.in was written? In the configure > scripts I've used, I have consistently seen the 'build' variables get > assigned the same values as the 'host' variables. You've seen broken scripts then. There may well be brain damaged scripts around. See http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC117 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/