There is an enum contained in some recent -mm versions of
linux/stddef.h which seems to be horking my glibc-2.4 compile:
enum {
false = 0,
true = 1
};
One way or another (I can't find where), 'true' and 'false' are
getting defined to 1 and 0, turning the above into enum { 0=0, 1=1 },
which though undeniable is not compilable.
This enum shows up in 2.6.18-rc5-mm1 and 2.6.18-mm1, but not in
2.6.17-mm6.
Whether this is the fault of glibc, gcc, or the kernel is a topic I
wouldn't touch with a 3m pole, even if I had one. I've submitted the
issue to the glibc bugzilla as well:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3301
Any thoughts would be appreciated.
Thanks,
Eric
On Wed, 2006-10-04 at 11:51 -0400, Eric Buddington wrote:
> There is an enum contained in some recent -mm versions of
> linux/stddef.h which seems to be horking my glibc-2.4 compile:
>
> enum {
> false = 0,
> true = 1
> };
>
> One way or another (I can't find where), 'true' and 'false' are
> getting defined to 1 and 0, turning the above into enum { 0=0, 1=1 },
> which though undeniable is not compilable.
I think you're making the mistake of using kernel headers for
userspace...... rather than the cleaned up headers.
Arjan van de Ven wrote:
> On Wed, 2006-10-04 at 11:51 -0400, Eric Buddington wrote:
>
>> There is an enum contained in some recent -mm versions of
>> linux/stddef.h which seems to be horking my glibc-2.4 compile:
>>
>> enum {
>> false = 0,
>> true = 1
>> };
>>
>> One way or another (I can't find where), 'true' and 'false' are
>> getting defined to 1 and 0, turning the above into enum { 0=0, 1=1 },
>> which though undeniable is not compilable.
>>
>
> I think you're making the mistake of using kernel headers for
> userspace...... rather than the cleaned up headers.
>
I think so too. glibc-2.4 #includes stdbool.h which have false/true
defined as 0/1.
Richard Knutsson