➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Include/pyport.h: Bad LONG_BIT assumption on non-glibc sys
Type: Stage:
Components: Build Versions: Python 2.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: cdgregorr, loewis, tim.peters
Priority: low Keywords:

Created on 2004-09-07 17:30 by cdgregorr, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg22385 - (view) Author: Gregor Richards (cdgregorr) Date: 2004-09-07 17:30 
While attempting to compile on Solaris 8 64-bit or HPUX 
64-bit, Python 2.3.4 has an "error" because LONG_BIT is 
not defined properly.  This error is incorrect on non-glibc 
systems, and Python compiles fine with it disabled.  
Here's the incorrect assumption:

#if LONG_BIT != 8 * SIZEOF_LONG
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 
64 on some recent
 * 32-bit platforms using gcc.  We try to catch that 
here at compile-time
 * rather than waiting for integer multiplication to trigger 
bogus
 * overflows.
 */
#error "LONG_BIT definition appears wrong for platform 
(bad gcc/glibc config?)."
#endif

This should include something to limit it to only glibc 
systems.

 - Gregor Richards
msg22386 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2004-09-07 17:57 
Logged In: YES 
user_id=31435

What are LONG_BIT and SIZEOF_LONG on these platforms?  
It doesn't matter whether gcc is being used, if LONG_BIT is 
defined incorrectly for the platform, then it's defined 
incorrectly period.

Read the comment you quoted to see why it doesn't matter 
whether Python "compiles fine" if you disable this.  It's 
guarding against runtime errors in Python's intobject.c, which 
needs a correct value for LONG_BIT.  Presumably LONG_BIT 
should be 64 on these boxes, and SIZEOF_LONG should be 8.
msg22387 - (view) Author: Gregor Richards (cdgregorr) Date: 2004-09-13 16:36 
Logged In: YES 
user_id=835341

I managed to track down the problem.  Both of these 
architectures require a cc flag to build in 64-bit mode, but the 
tests in configure were done without CFLAGS.  Thus, they 
build 32-bit, and the wrong values came out.
msg22388 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-09-14 07:55 
Logged In: YES 
user_id=21627

Did you specify CFLAGS during configure? If not, how did the
flags get added for 64-bit mode?
msg22389 - (view) Author: Gregor Richards (cdgregorr) Date: 2004-09-14 19:12 
Logged In: YES 
user_id=835341

export CC="/usr/bin/gcc"
export CFLAGS="-m64 -O2"
./configure

 - Gregor Richards
msg22390 - (view) Author: Gregor Richards (cdgregorr) Date: 2004-09-14 19:14 
Logged In: YES 
user_id=835341

By the way, I ended up making it work with

...
export CC="$CC $CFLAGS"
export CFLAGS=
./configure

However, this should not be necessary.
msg22391 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-09-26 17:37 
Logged In: YES 
user_id=21627

Setting CFLAGS during configure is currently not supported.
As a work-around, try setting BASECFLAGS in addition to
CFLAGS, or edit the generated Makefile.
History
Date User Action Args
2022-04-11 14:56:06adminsetgithub: 40881
2004-09-07 17:30:48cdgregorrcreate