Bug 19088 - <limits.h> mis-defines symbol LONG_BIT
<limits.h> mis-defines symbol LONG_BIT
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
: 19600 19996 20015 50849 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-13 17:05 EDT by Don Bennett
Modified: 2016-11-24 09:48 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-11-21 11:38:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Don Bennett 2000-10-13 17:05:02 EDT
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
Comment 1 Jakub Jelinek 2000-10-20 11:37:03 EDT
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).
Comment 2 Jakub Jelinek 2000-10-23 10:57:57 EDT
Ulrich actually checked it in, so you can expect it in the next glibc errata.
Comment 3 Jakub Jelinek 2000-10-23 10:59:32 EDT
*** Bug 19600 has been marked as a duplicate of this bug. ***
Comment 4 Jakub Jelinek 2000-10-30 01:22:46 EST
*** Bug 19996 has been marked as a duplicate of this bug. ***
Comment 5 Jakub Jelinek 2000-10-30 03:26:49 EST
*** Bug 20015 has been marked as a duplicate of this bug. ***
Comment 6 msuencks 2000-11-19 15:17:47 EST
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 ?
Comment 7 msuencks 2000-11-21 11:34:57 EST
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 ..
Comment 8 msuencks 2000-11-21 11:38:11 EST
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 ..
Comment 9 Jakub Jelinek 2001-08-07 09:00:48 EDT
*** Bug 50849 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.