Bug 19088
| Summary: | <limits.h> mis-defines symbol LONG_BIT | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Don Bennett <dpb> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED ERRATA | QA Contact: | David Lawrence <dkl> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.0 | CC: | fweimer |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2000-11-21 16:38:13 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 .. 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 .. |
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