initgroups.c: parse error before "__FUNCTION__"

[Rowan Potgieter]

>   I think that will be your underlying trouble: you're getting the post-3.2
> behaviour but the source was written originally for a pre-3.2 compiler.

hmmm so are saying that i'm going to have to rebuild the toolchain,
perhaps using an older version of gcc? pre 3.2? isn't that worse
though?

>   So, what's actually on line 179 before __FUNCTION__ ?

Copying from line 177-179:
      /* This is really only for debugging.  */
      if (NSS_STATUS_TRYAGAIN > status || status > NSS_STATUS_RETURN)
	__libc_fatal ("illegal status in " __FUNCTION__);

 I dont know if that helps...
Also is there anybody who can recommend a good gcc-glibc combination
for an arm-linux toolchain?
Thank you

On 11/08/06, Dave Korn <dave.korn@artimi.com> wrote:
> On 11 August 2006 16:03, Rowan Potgieter wrote:
>
> > I'm in the process of compiling the snapgear 2.4.x kernel for a IXP425
> > processor and I'm using a toolchain I built with crosstool-0.42.
> > Previous to this I had a problem with "short-load-bytes" which I fixed
> > by simply changing -mshort-load-bytes in the Makefile to
> > -malignment-traps and that seemed to have worked. Now however I have
> > the following problem, I doubt they're related but I mentioned it just
> > in case:
>
> > initgroups.c: In function `internal_getgrouplist':
> > initgroups.c:179: error: parse error before "__FUNCTION__"
>
>   So, what's actually on line 179 before __FUNCTION__ ?
>
> > The toolchain I built was GCC-3.4.4 and glibc-2.3.3, could the above
> > error be related??
>
>   It could perhaps be gcc version-related; I have a vague memory that the
> nature of __FUNCTION__ got changed at some point, let me check, aha!  See the
> gcc manual, section 5.41, "Function Names as Strings":
>
>
> ---------------------------------------<quote>--------------------------------
> ------
>    The compiler automagically replaces the identifiers with a string
> literal containing the appropriate name.  Thus, they are neither
> preprocessor macros, like `__FILE__' and `__LINE__', nor variables.
> This means that they catenate with other string literals, and that they
> can be used to initialize char arrays.  For example
>
>      char here[] = "Function " __FUNCTION__ " in " __FILE__;
>
>    On the other hand, `#ifdef __FUNCTION__' does not have any special
> meaning inside a function, since the preprocessor does not do anything
> special with the identifier `__FUNCTION__'.
>
>    Note that these semantics are deprecated, and that GCC 3.2 will
> handle `__FUNCTION__' and `__PRETTY_FUNCTION__' the same way as
> `__func__'.  `__func__' is defined by the ISO standard C99:
>
>      The identifier `__func__' is implicitly declared by the translator
>      as if, immediately following the opening brace of each function
>      definition, the declaration
>           static const char __func__[] = "function-name";
>
>      appeared, where function-name is the name of the lexically-enclosing
>      function.  This name is the unadorned name of the function.
>
>    By this definition, `__func__' is a variable, not a string literal.
> In particular, `__func__' does not catenate with other string literals.
> ---------------------------------------<quote>--------------------------------
> ------
>
>   I think that will be your underlying trouble: you're getting the post-3.2
> behaviour but the source was written originally for a pre-3.2 compiler.
>
>     cheers,
>       DaveK
> --
> Can't think of a witty .sigline today....
>
>


-- 
--------------------------------------------------------------------------------------------------------------------------------------------
 When you say 'I wrote a program that crashed Windows', people just
stare at you blankly and say 'Hey, I got those with the system, *for
free*'. (L. Torvalds)
--------------------------------------------------------------------------------------------------------------------------------------------

--
For unsubscribe information see http://sourceware.org/lists.html#faq