From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9373 invoked by alias); 23 Jan 2012 00:59:11 -0000 Received: (qmail 9365 invoked by uid 22791); 23 Jan 2012 00:59:10 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jan 2012 00:58:57 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id q0N0wt103034; Mon, 23 Jan 2012 00:58:55 GMT Received: from lert.jifvik.org (lert.jifvik.org [172.31.1.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 040783FE1; Mon, 23 Jan 2012 00:58:53 +0000 (GMT) Message-ID: <4F1CB0CD.70006@jifvik.org> Date: Mon, 23 Jan 2012 00:59:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Sergei Gavrikov Cc: eCos developers Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00032.txt.bz2 On 14/01/12 16:01, Sergei Gavrikov wrote: > > Also we would take a look at the RTEMS (CVS -> 4.11) patches for their > latest toolchain sources as they does use GCC 4.6.1 & binutils 2.21 for > RTEMS (CVS) builds > > http://www.rtems.org/ftp/pub/rtems/SOURCES/4.11/ > > By the way I like their built-in __rtems__ definition for own GCC builds > and I guess in the end we would propagate __ecos__ for own ones on the > occasion of renewal. What do you think? For reasons other people mentioned, I'd be against this. > IMHO, we also would start to use own labels in the prefixes for eCos > toolchains (http://gcc.gnu.org/install/specific.html). What do you think > about 'ecos' label in the prefixes as an OS-label? In ideal world the > prefixes would be *-*-ecos2.0, *-*-ecos3.0, *-*-ecos4.0 for toolchains > for eCos major releases to prevent the PATH collisions, and, perhaps, > *-*-ecos., for eCos middle time (not full tested) releases, > e.g. i386-elf-ecos3.12-gcc for 2012. And may be to have *-*-ecos as the > prefixes is quite enough for us. (Excuse, if above looks like > OFF-TOPIC). No, definitely nothing with versions in the tuple like that. There could be an argument for a ARCH-ecos-elf tuple, for example. arm-eabi-ecos-elf. But it's not a very good argument. We risk breaking backward compatibility, and also compatibility with important toolchain providers such as Codesourcery, who provide toolchains aimed at the newlib runtime, but which eCos users can nevertheless use. We would no longer be able to do that. Asking those eCos users to rebuild the toolchain for the eCos OS target would not be right as Codesourcery support toolchain binaries, and not rebuilt toolchains, even from the same source base. > IMHO, if we won't see volunteers for non arm-eabi targets also we should > test new toolchain for Linux synthetic target at least (it would help us > in the efforts on warning clean-ups for new toolchain). The Linux synthetic target uses the native toolchain, and as we've found from bitter experience, different distros add their own wacky patches (yes, Ubuntu and friends, I'm looking at you). People can look at warnings on any architecture - you don't have to have a board after all just to compile. Jifl