From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6119 invoked by alias); 22 Jan 2009 10:31:34 -0000 Received: (qmail 6107 invoked by uid 22791); 22 Jan 2009 10:31:33 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from rubicon.hasler.ascom.ch (HELO rubicon.hasler.ascom.ch) (139.79.129.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Jan 2009 10:31:26 +0000 Received: from eiger.ma.tech.ascom.ch (eiger.ma.tech.ascom.ch [139.79.100.1]) by rubicon.hasler.ascom.ch (8.14.1/8.14.1) with ESMTP id n0MAVJMo021752; Thu, 22 Jan 2009 11:31:19 +0100 (MET) Received: from [139.79.100.143] (helo=donkey.ma.tech.ascom.ch) by eiger.ma.tech.ascom.ch with esmtp (Exim 3.16 #1) id 1LPwqD-0006Kv-00; Thu, 22 Jan 2009 11:31:17 +0100 Received: from lunn by donkey.ma.tech.ascom.ch with local (Exim 3.36 #1 (Debian)) id 1LPwqF-0007In-00; Thu, 22 Jan 2009 11:31:19 +0100 Date: Thu, 22 Jan 2009 10:31:00 -0000 From: Andrew Lunn To: John Dallaway Cc: Jonathan Larmour , ecos-maintainers@ecos.sourceware.org Subject: Re: Building RedBoot for SH3 targets with new toolchain Message-ID: <20090122103119.GG7080@donkey.ma.tech.ascom.ch> References: <49777C14.8070201@dallaway.org.uk> <497785C0.50004@eCosCentric.com> <49779CC3.2000202@dallaway.org.uk> <4977A2A8.1030608@eCosCentric.com> <4977B0E2.3040806@dallaway.org.uk> <4977BDF1.1060304@eCosCentric.com> <49784728.50700@dallaway.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49784728.50700@dallaway.org.uk> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-01/txt/msg00018.txt.bz2 > Taking all these things into account, plus the desire to avoid further > delays to the eCos 3.0 release, I think it preferable to stick with the > stock mpfr and gmp DLLs for the Cygwin-hosted toolchains. We must > document the need to install the relevant Cygwin packages though, and > add an entry to the FAQ. Would it be possible to detect at build time if these DLLs are installed? But a custom build rule with the highest priority in infra, or HAL which will test if this files exist and stop and print an useful error message if they are not installed? The way cygwin is silently failing is not nice... Andrew