From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14805 invoked by alias); 22 Jan 2009 16:59:50 -0000 Received: (qmail 14794 invoked by uid 22791); 22 Jan 2009 16:59:49 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtaout03-winn.ispmail.ntl.com (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Jan 2009 16:59:42 +0000 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090122165836.KPCH7670.mtaout03-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Thu, 22 Jan 2009 16:58:36 +0000 Received: from cog.dallaway.org.uk ([213.106.81.244]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090122165836.GAMA22934.aamtaout04-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Thu, 22 Jan 2009 16:58:36 +0000 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id n0MGwQ1H020702; Thu, 22 Jan 2009 16:58:26 GMT Message-ID: <4978A5B2.1050901@dallaway.org.uk> Date: Thu, 22 Jan 2009 16:59:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.19 (X11/20090107) MIME-Version: 1.0 To: Bart Veer CC: ecos-maintainers@ecos.sourceware.org Subject: Re: Building RedBoot for SH3 targets with new toolchain 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> <20090122103119.GG7080@donkey.ma.tech.ascom.ch> <497866C6.80009@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00021.txt.bz2 Hi Bart Bart Veer wrote: >>>>>> "John" == John Dallaway writes: > > John> Hi Andrew > John> Andrew Lunn wrote: > > >>> 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... > > John> The failure mode is certainly not nice. I expect that the > John> mpfr and gmp DLLs are loaded explicitly by the compiler > John> using LoadLibrary() and failure is not being reported at the > John> application level. > > John> We could emit a _warning_ message using a custom rule. An > John> _error_ message would be too strong since older toolchains > John> do not use mpfr and gmp. However, it seems cleaner to keep > John> such testing out of the build process and perform the tests > John> in the eCos install script instead when the relevant > John> toolchains are being installed. Having said that, I > John> appreciate that experienced eCos developers may not use the > John> install script. > > Just how much does it save to link mpfr and gmp dynamically instead of > statically? Ditto for intl and iconv? I cannot quantify the size and performance savings without experimentation, but I do know that using the DLLs is the right approach for Windows hosts. If GCC is using LoadLibrary() for the mpfr and gmp DLLs then the correct fix would be to patch GCC to report the failure. However, tying such a fix (and the preceding investigation) to the forthcoming release would not be appropriate at this stage in the release cycle. Lets keep focussed on the remaining critical issues for eCos 3.0. John Dallaway