From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5102 invoked by alias); 17 Jan 2012 12:28:23 -0000 Received: (qmail 5086 invoked by uid 22791); 17 Jan 2012 12:28:20 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bk0-f49.google.com (HELO mail-bk0-f49.google.com) (209.85.214.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 12:28:07 +0000 Received: by bkty8 with SMTP id y8so7506181bkt.36 for ; Tue, 17 Jan 2012 04:28:06 -0800 (PST) Received: by 10.204.153.195 with SMTP id l3mr3484760bkw.123.1326803285787; Tue, 17 Jan 2012 04:28:05 -0800 (PST) Received: from sg-pc.belvok.com ([86.57.137.251]) by mx.google.com with ESMTPS id d2sm46819353bky.11.2012.01.17.04.28.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 04:28:04 -0800 (PST) Date: Tue, 17 Jan 2012 12:28:00 -0000 From: Sergei Gavrikov To: Paul Beskeen cc: ecos-devel@ecos.sourceware.org Subject: Re: Gnutools: consideration for upgrade to GCC 4.6 In-Reply-To: <4F154F95.30203@ecoscentric.com> Message-ID: References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> <4F154606.3050507@kuantic.com> <4F154F95.30203@ecoscentric.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463803648-1976998740-1326803284=:13451" X-IsSubscribed: yes 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/msg00027.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463803648-1976998740-1326803284=:13451 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-length: 1977 All I changed my mind. I withdraw my request. All should know what (which toolchain) they use. If I do not trust myself, no one denies to patch GCC to get own built-in define, e.g. __home_cooked__ as a memory stick to distinguish toolchains :-) Thanks for your points and time! Sergei On Tue, 17 Jan 2012, Paul Beskeen wrote: > On 17/01/2012 09:57, Bernard Fouché wrote: > > Le 16/01/2012 22:11, Sergei Gavrikov a écrit : > >> On Mon, 16 Jan 2012, Sergei Gavrikov wrote: > >> > >>> I hope I have convinced you and Stano that I did not suggest to > >>> "close" eCos sources by __ecos__ checks. More that to propagate > >>> that built-in definition is only a few lines for GCC patch and if > >>> that is issue I am ready to withdraw my "I like their built-in" > >>> :-) > >> Nobody (me too) said (thought) about: > >> > >> http://www.ecoscentric.com/trademark_usage.shtml > >> > >> AIANL. So, I actually withdraw my "wish" as [eCos] is registered > >> trademark and anyone would use our patches and abuse the word. > >> > >> Sergei > > > > Being able to identify/check the toolchain used seems a very good > > idea. Why not ask eCosCentric about the legal issue? They already > > make a toolchain available for public eCos, that can be installed > > with the installation tool (see > > http://ecos.sourceware.org/getstart.html) . IMHO it is in the > > interest of eCos to avoid having its public image altered because of > > bugs that are related to the toolchain and not eCos itself. > > On the trademark front there is no issue with the public eCos release > using this as required (see 1.1.1/4 section in the above referenced > URL). > > On a personal note, I would however avoid the use of __ecos__ in the > toolchain for all the reasons that Grant has already pointed out. > Critically, you don't want to limit users to a specific set of > toolchains. > > Regards, Paul. > -- > Paul Beskeen, Chairman & Director of Engineering > http://www.ecoscentric.com/ > ---1463803648-1976998740-1326803284=:13451--