From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32146 invoked by alias); 4 Feb 2009 09:22:34 -0000 Received: (qmail 32136 invoked by uid 22791); 4 Feb 2009 09:22:33 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtaout02-winn.ispmail.ntl.com (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Feb 2009 09:22:27 +0000 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090204092224.FKPD4080.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Wed, 4 Feb 2009 09:22:24 +0000 Received: from cog.dallaway.org.uk ([213.106.81.244]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090204092224.VHMQ21638.aamtaout02-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Wed, 4 Feb 2009 09:22:24 +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 n149MIQD011763; Wed, 4 Feb 2009 09:22:18 GMT Message-ID: <49895E4A.6030208@dallaway.org.uk> Date: Wed, 04 Feb 2009 09:22: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: Target-specific build failures [ was Re: eCos 3.0 beta 1 punch list #1 ] References: <4985E0F9.5020809@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-02/txt/msg00005.txt.bz2 Hi Bart and all Bart Veer wrote: >>>>>> "John" == John Dallaway writes: > > John> b) CDL changes to split compiler warning flags out into a > John> separate CDL option. (bartv) > > This is now complete. I have now finished in the hal/ directory, so I > have no objection to people checking in more changes in there. That's great news. Thank you. > There are an awful lot of platforms which fail to build. > > ARM > AEB, all SA1110: cxxsupp fails to link because of .gcc_except_table. This on the punch list for jifl to investigate. [ snip various build failures ] Most of the failures you list are for old/obsolete targets that may no longer be in use within the eCos community. While we could systematically go through all these failures, I don't see this as a good use of our time right now. We know that architectural support for the main architectures is in good shape. Everyone, if there are targets in the list that you care about, please volunteer to fix as soon as possible. > SH > All platforms fail to build cxxsupp I have a patch for this issue. > I have not tried anything with the calmrisc16, calmrisc32, coldfire, > fr30, frv, h8300, mn10300, openrisc, sparc, sparclite or v85x targets. The old "coldfire" HAL and associated target will not form part of the release. The other architectures will simply not be tested (even for build regressions) unless someone shows an interest in these targets. > The synthetic target builds fine, but there is a run-time problem with > cxxsupp. It appears that libgcc now assumes that glibc has done some > initialization, setting up the %gs register to point at per-thread > data. This came up previously in the context of the -fstack-protector > flag, see the mailing list archives, but at the time we decided we > could live with the problem. It looks like there are now more > dependencies on getting this sorted - which I suspect will prove > challenging. We always seem to be playing catch up with gcc/glibc for the synthetic target. If you have time to investigate the cxxsupp build failure then, of course, feel free. However, I don't see this as a showstopper, at least not for the beta release. We can always document the compatibility issue in the README. For avoidance of doubt, please do finish off the constructor priority re-work first so we can unfreeze the repository for final check-ins and I can commence further sanity tests across the entire repository. When do you envisage being able to check this in? Jifl/Bart, could we limit the scope of the code freeze to those packages that form part of the constructor priority re-work now? John Dallaway