#define collision: LONG_BIT

[complex]

BPO	419012
Nosy	@tim-one

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2001-04-26.01:31:10.000>
created_at = <Date 2001-04-26.01:08:43.000>
labels = ['build', 'invalid']
title = '#define collision: LONG_BIT'
updated_at = <Date 2001-04-26.01:31:10.000>
user = 'https://bugs.python.org/complex'

bugs.python.org fields:

activity = <Date 2001-04-26.01:31:10.000>
actor = 'tim.peters'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2001-04-26.01:08:43.000>
creator = 'complex'
dependencies = []
files = []
hgrepos = []
issue_num = 419012
keywords = []
message_count = 2.0
messages = ['4527', '4528']
nosy_count = 2.0
nosy_names = ['tim.peters', 'complex']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue419012'
versions = []

[complex]

Platform: RedHat Linux 7.0, Linux kernel 2.2.17

When building Python 2.1 final release after

./configure --prefix=/usr/local

LONG_BIT definition found in
/usr/local/include/bits/xopen_lim.h causes an error
message originated from LONG_BIT size test in Python.h.

Workaround (only an ugly hack): Insert "#define
LONG_BIT 32" in Python.h before the #ifndef LONG_BIT
line. This causes a #define collision warning, but
Python 2.1 compiles successfully and works.

• Complex -

[tim-one]

Logged In: YES
user_id=31435

The GCC version that comes with Red Hat 7.0 is not fit for
distribution.

In particular, it defines LONG_BIT as 64 on 32-bit machines under
certain circumstances, and letting this go unchecked would cause
it to generate bad code for various Python arithmetic operations.

The solution is to download a valid version of GCC.

See

http://www.python.org/cgi-
bin/moinmoin/FrequentlyAskedQuestions#line53

for more information.