public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@jifvik.org>
To: Sergei Gavrikov <sergei.gavrikov@gmail.com>
Cc: eCos developers <ecos-devel@ecos.sourceware.org>
Subject: Re: Gnutools: consideration for upgrade to GCC 4.6
Date: Mon, 23 Jan 2012 00:59:00 -0000	[thread overview]
Message-ID: <4F1CB0CD.70006@jifvik.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1201141854480.2289@vostro>

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<major>.<year>, 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

  parent reply	other threads:[~2012-01-23  0:59 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-13 17:01 Ilija Kocho
2012-01-13 18:54 ` Bernard Fouché
2012-01-13 19:39   ` Ilija Kocho
2012-01-13 19:09 ` Frank Pagliughi
2012-01-13 19:45   ` Ilija Kocho
2012-01-14 10:22 ` John Dallaway
2012-01-14 16:02   ` Sergei Gavrikov
2012-01-15 17:36     ` Grant Edwards
2012-01-15 18:42       ` Sergei Gavrikov
2012-01-15 21:39         ` Stanislav Meduna
2012-01-23  1:01           ` Jonathan Larmour
2012-01-15 22:21         ` Ilija Kocho
2012-01-15 22:21         ` Ilija Kocho
2012-01-23  1:07           ` Jonathan Larmour
2012-01-16 15:20         ` Grant Edwards
2012-01-16 20:43           ` Sergei Gavrikov
2012-01-16 21:11             ` Sergei Gavrikov
2012-01-17  9:58               ` Bernard Fouché
2012-01-17 10:38                 ` Paul Beskeen
2012-01-17 12:28                   ` Sergei Gavrikov
2012-01-23  0:59     ` Jonathan Larmour [this message]
2012-01-14 16:25   ` Ilija Kocho
2012-01-23  1:13     ` Jonathan Larmour
2012-01-23 18:40       ` Ilija Kocho
2012-01-23 19:29         ` Jonathan Larmour
2012-01-25 12:30         ` Alex Schuilenburg
2012-01-25 20:59           ` Ilija Kocho
2012-01-26 13:36             ` Alex Schuilenburg
2012-01-26 20:18               ` Ilija Kocho
2012-02-13 22:02           ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Ilija Kocho
2012-02-20 16:00             ` Alex Schuilenburg
2012-02-20 20:45               ` Ilija Kocho
2012-03-02 16:36             ` Alex Schuilenburg
2012-03-03 13:32               ` Ilija Kocho
2012-03-04  0:10                 ` Alex Schuilenburg
2012-03-04 17:49                   ` Sergei Gavrikov
2012-03-04 23:08                     ` Alex Schuilenburg
2012-03-04 19:37                   ` eCos GNU tools 4.6.2-20120125 ready for testing John Dallaway
2012-03-04 23:47                     ` Alex Schuilenburg
2012-03-05  8:00                       ` Sergei Gavrikov
2012-03-07 13:51                         ` Sergei Gavrikov
2012-03-07 11:58                       ` Alex Schuilenburg
2012-03-07 13:01                         ` Ilija Kocho
2012-03-07 13:39                           ` Sergei Gavrikov
2012-03-07 13:13                         ` John Dallaway
2012-03-12 16:43                           ` Alex Schuilenburg
2012-03-16 15:05                             ` Alex Schuilenburg
2012-03-08 17:28                         ` Alex Schuilenburg
2012-03-09  9:39                           ` Ilija Kocho
2012-03-09 17:15                             ` Alex Schuilenburg
2012-03-10 17:16                           ` John Dallaway
2012-03-12 16:12                             ` Alex Schuilenburg
2012-03-13 13:31                               ` Alex Schuilenburg
2012-03-13 14:16                                 ` Ilija Kocho
2012-03-13 17:47                                   ` Sergei Gavrikov
2012-03-15  8:50                                     ` John Dallaway
2012-03-17 14:50                                       ` Sergei Gavrikov
2012-03-17 20:58                                         ` John Dallaway
2012-03-17 16:44                                       ` Stanislav Meduna
2012-03-18 19:10                                   ` eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing] Ilija Kocho
2012-04-04 12:57                                     ` Lambrecht Jürgen
2012-04-04 13:18                                       ` Ilija Kocho
2012-05-31  8:42                                         ` eCos GNU tools 4.6.3-20120315 and link time optimization Bernard Fouché
2012-03-05  8:30                     ` eCos GNU tools 4.6.2-20120125 ready for testing Tomas Frydrych
2012-03-05  8:56                       ` Tomas Frydrych
2012-03-05  9:50                         ` John Dallaway
2012-03-05  9:55                           ` Anders Montonen
2012-03-05 14:20                             ` John Dallaway
2012-03-05 10:16                           ` Ilija Kocho
2012-03-05 12:56                             ` Tomas Frydrych
2012-03-03 12:58             ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Sergei Gavrikov
2012-01-17  9:37 ` Gnutools: consideration for upgrade to GCC 4.6 Tomas Frydrych
2012-01-17 16:10   ` Stanislav Meduna
2012-01-17 16:25     ` Tomas Frydrych
2012-01-17 16:45     ` Ilija Kocho
2012-01-20 14:42       ` Frank Pagliughi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F1CB0CD.70006@jifvik.org \
    --to=jifl@jifvik.org \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=sergei.gavrikov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).