initgroups.c: parse error before "__FUNCTION__"

Dave Korn
Fri Aug 11 15:15:00 GMT 2006

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

   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.

  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.

Can't think of a witty .sigline today....

For unsubscribe information see

More information about the crossgcc mailing list