Re: Gnutools: consideration for upgrade to GCC 4.6

[Sergei Gavrikov <sergei.gavrikov@gmail.com>]

On Mon, 16 Jan 2012, Grant Edwards wrote:

> On 2012-01-15, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> > On Sun, 15 Jan 2012, Grant Edwards wrote:
> >
> >> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> >> 
> >> > 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.
> >> 
> >> Why?
> >
> > Simply to distinguish the official releases of toolchains (I hope
> > well tested) and any home-cooked toolchains. I meant such predefined
> > things for GCC (CPP)
> 
> I realize it would distinguish official toolchains from others.  What
> I want to know is why that's useful.
> 
> >   % i386-rtems4.11-gcc -dM -E - </dev/null | grep __rtems__
> >   #define __rtems__ 1
> >
> > and the same we could have for officially supported releases for
> > ecos, e.g.
> >
> >   % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
> >   #define __ecos__ 1
> >
> > Secondly, it lets anyone to use such checks in sources, e.g.
> >
> >   #if __linux__
> >   # include <endian.h>
> >   #elif __ecos__
> >   # include <machine/endian.h>
> >   #else
> >   ...
> >   #endif
> 
> That doesn't seem to be appropriate to me.  In eCos builds, the
> include files are not part of the toolchain and their locations
> shouldn't be determined based on the toolchain.  The eCos include
> files are part of the eCos source tree and build system (which
> provides __ECOS__).

I agree, snippet above does confuse most of you. I would defend it, but,
I do not want to do so as I do not desire to change the *Subject* of
this thread.  (I'm sorry Ilija)

> > For now we usually add '-D__ECOS__' to CFLAGS for some packages.

To be clear, I did not offer neither to remove nor replace -D__ECOS__
from CFLAGS in eCos config files. I'm sorry if you've seen this.

> > The third, Why we should avoid to say that eCos is also well known,
> > widely used OS?
> 
> For one thing, I use the same toolchain to build eCos stuff and
> non-eCos stuff.  The __ECOS__ macro can be used to tell the
> difference.
> 
> >> Are the eCos sources going to start requiring use of specific
> >> toolchain binaries?
> >
> > Nope. Anyone can use own binaries if he/she wants.
> 
> Not if eCos code is going to contain checks for __ecos__ that cause a
> build to fail without __ecos__.

I ever did not think about. I did not plan to implant such checks in
*eCos sources*.  I did not say, we should  s/__ECOS__/__ecos__/g.  I
wrote:

> >> > 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.

> >> I've been using eCos for a long time, and have always used my own
> >> toolchains.  I'd be pretty unhappy if that was no longer possible.
> >
> > Why it will be not possible? I did not understand.
> 
> If the eCos code is going to be checking for __ecos__ then that code
> won't build with my toolchains.

Once again that was not attempt of any revisionism for eCos sources.
IMHO, built-in CPP definition (__ecos__) can be useful a) for portable
userland applications (not eCos sources); b) for shell scripts which
would detect toolchain easier; c) to distinguish home cooked or third
party toolchains from eCos stable ones (that was my main idea). I risk
to paste yet another check

    /*
     * NOTE: I do not offer such a check for eCos sources itself.
     */
  #ifdef __ECOS__
  # if !defined(__ecos__)
  #  warn Used wrong toolchain for mission critical application.
  #  BUG()
  # endif
  #endif

But. Can such check exist in userland application? [Not need to answer]

> > You can use own, but, a bug reporter should/may use officially
> > supported "labeled" toolchain to check the roots of some issue on
> > crashes. But, naturally, I do not resists on built-in label
> > __ecos__.  Look on that as a promotion eCos OS. If you think that my
> > points are wrong, please, forget it.
> 
> As long as nothing in the build process checks for or requires
> __ecos__, then that's fine.

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" :-)

Let's move on to the subject of the thread. It seemed for me that all of
us are interested in new toolchain(s) and if you are the experts here,
let's open Bugzilla entry for this, there we would accumulate a set of
patches for new toolchain base.

Sergei

> -- 
> Grant Edwards               grant.b.edwards        Yow! Hey, wait
>                                   at               a minute!!  I want a
>                               gmail.com            divorce!! ... you're not
>                                                    Clint Eastwood!!
>