[ELDK] [PATCH] usr/include/error.h, argp.h, and n?curses.h

[Ryan Thompson]

Hi Detlev,

Thanks for the reply. I have a little more information that should
prove helpful.

On Fri, Sep 25, 2009 at 8:05 AM, Detlev Zundel <dzu at denx.de> wrote:
> Hy Ryan,
>
> > #including <error.h>, argp.h or n?curses.h breaks __attribute__ , such
> > that no __attribute__ types will be applied, on any source (including
> > other #includes) after the offending #include.
>
> I'm sorry, but this really makes no sense for me.

OK, see below.

> Did you use native or cross-toolchain?

I'm cross compiling for ppc_4xx.

And, I should have included my compiler flags: after seeing your
success, I narrowed the compiler flags down to the following minimal
case:

$ ppc_4xx-gcc -std=c99 s1.c -o s1

In other words, c99 mode is sufficient to trigger the bug with
<error.h> et. al. Looking at the relevant ppc_4xx/usr/include/error.h
code (the code I proposed removing in my patch), it's easy to see why:

#ifndef __attribute__
/* This feature is available in gcc versions 2.5 and later.  */
# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 5) || __STRICT_ANSI__
#  define __attribute__(Spec) /* empty */
# endif
/* The __-protected variants of `format' and `printf' attributes
   are accepted by gcc versions 2.6.4 (effectively 2.7) and later.  */
# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 7)
#  define __format__ format
#  define __printf__ printf
# endif
#endif

-std=c99 defines __STRICT_ANSI__, which (per the above code) causes
__attribute__ to always be silently clobbered when error.h et. al. are
#included. (#ifndef __attribute__ is always true with gcc, regardless
of the c99 flag, so that check is meaningless.) So I assume we'd see
the same thing with -std=c89, -ansi, etc.

> > The Fix:
> > My patch removes __attribute__ redefinition from the eldk's include
> > files. This code appears to be a defensive kludge for GCC < 2.5, so
> > the risk of regressions on GCC 4.x is extremely low.
>
> You fix a problem that we do not have, so I presume the real cause for
> your trouble is somewhere else.  Try to find that instead.

This still appears to be ELDK specific. Would you give this another
look, please?

Thanks,
- R