This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gnutools: consideration for upgrade to GCC 4.6


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]