This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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....
--
For unsubscribe information see http://sourceware.org/lists.html#faq
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |