Red Hat Bugzilla – Bug 19088
<limits.h> mis-defines symbol LONG_BIT
Last modified: 2016-11-24 09:48:13 EST
Some of the system limits are screwed up.
I have determined that:
which turns around and once again includes
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
but the original compiler version of limits.h (1) hasn't yet defined
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.
#define _GNU_SOURCE 1
printf("size of long: %d\n", sizeof(long));
printf("LONG_BIT: %d\n", LONG_BIT);
[dpb@cayenne] 239% ./testing
size of long: 4
I think I have fixed this in
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. ***