Some of the system limits are screwed up. I have determined that: 1) /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/limits.h includes 2) /usr/lib/gcc-lib/i396-redhat-linux/2.96/include/syslimits.h which turns around and once again includes 3) /usr/lib/gcc-lib/i396-redhat-linux/2.96/include/limits.h, but the second time _GCC_LIMITS_H is already defined, so it goes ahead and pulls in /usr/include/ limits.h, which in turn pulls in /usr/include/bits/xopen_lim.h. This file counts on INT_MAX being defined before it is included (or I get an incorrect default) but the original compiler version of limits.h (1) hasn't yet defined that symbol. I tried a few things to work around the problem, but I think I will rather change my code not to depend on LONG_BIT. Test program: #define _GNU_SOURCE 1 #include <limits.h> main() { printf("size of long: %d\n", sizeof(long)); printf("LONG_BIT: %d\n", LONG_BIT); } Sample output: [dpb@cayenne] 239% ./testing size of long: 4 LONG_BIT: 64
I think I have fixed this in http://sources.redhat.com/ml/libc-hacker/2000-10/msg00064.html I'm now waiting for it being reviewed, if Uli agrees with that solution, it will make into next glibc errata. Thanks for noticing this (btw: if you passed -I/usr/include on the command line, LONG_BIT and WORD_BIT would have proper values).
Ulrich actually checked it in, so you can expect it in the next glibc errata.
*** Bug 19600 has been marked as a duplicate of this bug. ***
*** Bug 19996 has been marked as a duplicate of this bug. ***
*** Bug 20015 has been marked as a duplicate of this bug. ***
I've already upgraded to glibc-devel-2.1.94-3.i386.rpm which still brings the mentioned problem ( specifially I want to build Python 2.0) what files I am supposed to patch anyway - those under /usr/include or those under /usr/lib/gcc-lib ?
more specific: the Python FAQ states that I can work around the LONG_BIT error by running "configure" like this: CC="gcc -DINT_MAX=2147483647" ./configure however this works only with the headers from glibc-2.1.92 but not with the 2.1.94 update ..
*** Bug 50849 has been marked as a duplicate of this bug. ***