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] |
> if (NSS_STATUS_TRYAGAIN > status || status > NSS_STATUS_RETURN) > __libc_fatal ("illegal status in internal_getgrouplist");
That worked perfectly - I came across a similar problem a bit further along though:
nsswitch.c: In function `__nss_next': nsswitch.c:181: error: parse error before "__FUNCTION__"
I'm applying the same fix - it should work thanks for all your help! rowan
On 11 August 2006 16:27, Rowan Potgieter wrote:
>> 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?
Nope, it will be much easier to hack the source to update it:
>> 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...
Absolutely it does. In old gcc, __FUNCTION__ was a string, so that line looks like this:
> if (NSS_STATUS_TRYAGAIN > status || status > NSS_STATUS_RETURN) > __libc_fatal ("illegal status in " "internal_getgrouplist");
and it's using preprocessor string contcatenation to make that into one message. But the new way of doing things, __FUNCTION__ is effectively a variable like __func__:
>> 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.
Note that last line: what you have with modern gcc is effectively
> static const char __FUNCTION__[] = "internal_getgrouplist"; > > if (NSS_STATUS_TRYAGAIN > status || status > NSS_STATUS_RETURN) > __libc_fatal ("illegal status in " __FUNCTION__);
and of course, you can't concatenate the runtime contents of a variable with a literal string at compile time!
I don't know if __libc_fatal accepts format specifiers, but if it does, the solution /could/ be as simple as rewriting it to
> if (NSS_STATUS_TRYAGAIN > status || status > NSS_STATUS_RETURN) > __libc_fatal ("illegal status in %s", __FUNCTION__);
otherwise, you'd need to strcat or sprintf it into a temporary buffer, or just make do without the function name, or hard-code it into the error message:
> if (NSS_STATUS_TRYAGAIN > status || status > NSS_STATUS_RETURN) > __libc_fatal ("illegal status in internal_getgrouplist");
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |