Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 139911 - libxml failes to compile with -m32: LONG_BIT complaint in pyport.h
Summary: libxml failes to compile with -m32: LONG_BIT complaint in pyport.h
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: python
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On: 192747
Blocks: 201434
TreeView+ depends on / blocked
 
Reported: 2004-11-18 19:06 UTC by Ben Greear
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: 2.4.3-15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-17 22:19:19 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Ben Greear 2004-11-18 19:06:14 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
I am trying to build a 32-bit executable of libxml.  The build fails
with this error:

 gcc -m32 -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/python2.3
-I../include -g -O2 -Wall -MT libxml.lo -MD -MP -MF .deps/libxml.Tpo
-c libxml.c  -fPIC -DPIC -o .libs/libxml.o
In file included from /usr/include/python2.3/Python.h:48,
                 from libxml.c:14:
/usr/include/python2.3/pyport.h:554:2: #error "LONG_BIT definition
appears wrong for platform (bad gcc/glibc config?)."

From looking at similar reports, the Python folks seem to claim this
is a compiler error.

My makefile target has these commands, which should allow you to
reproduce the problem:

	rm -fr libxml2-2.6.11
	tar -xvzf libxml2-2.6.11.tar.gz
	(cd libxml2-2.6.11; CC="gcc -m32" CXX="g++ -m32" ./configure
--without-threads)
	(CC="gcc -m32" CXX="g++ -m32" make -C libxml2-2.6.11)


The pyport.h code that fails looks like this:

#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

#ifdef __cplusplus
}
#endif


Version-Release number of selected component (if applicable):
gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

How reproducible:
Always

Steps to Reproduce:
1.

	rm -fr libxml2-2.6.11
	tar -xvzf libxml2-2.6.11.tar.gz
	(cd libxml2-2.6.11; CC="gcc -m32" CXX="g++ -m32" ./configure
--without-threads)
	(CC="gcc -m32" CXX="g++ -m32" make -C libxml2-2.6.11)


2.
3.
    

Actual Results:  Compile failed:

 gcc -m32 -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/python2.3
-I../include -g -O2 -Wall -MT libxml.lo -MD -MP -MF .deps/libxml.Tpo
-c libxml.c  -fPIC -DPIC -o .libs/libxml.o
In file included from /usr/include/python2.3/Python.h:48,
                 from libxml.c:14:
/usr/include/python2.3/pyport.h:554:2: #error "LONG_BIT definition
appears wrong for platform (bad gcc/glibc config?)."


Expected Results:  Compile should complete successfully.

Additional info:

up2date FC3 for x86-64.

Dual-processor Opteron system.
Comment 1 Ben Greear 2004-11-18 19:16:12 UTC 
For a work-around, can configure with: --without-python
Comment 2 Jakub Jelinek 2004-11-18 20:04:07 UTC 
This is python bug.
Some of its headers aren't multi-abi agnostic.
Particularly pyconfig.h contains a bunch of SIZEOF_* defines that are specific
to the arch on which that header was created.

To cure, I'd suggest to diff all python headers between the multilib arch
pairs (i386/x86_64, ppc/ppc64, s390/s390x) and deal with the differences.
Particularly for the SIZEOF_* defines, one solution is to change them from
constants to sizeof (long), sizeof (double) etc.  In C that should make absolutely no difference, for C++ it might matter that the constants ATM defined
are int type, while sizeof () would be size_t.  So maybe ((int) sizeof (long)).

Alternatively, you can e.g. #include <bits/wordsize.h> in that header and
#if __WORDSIZE == 32 define the constants one way #elif __WORDSIZE == 64 another way #endif.  Or you can have 3 pyconfig.h headers, say pyconfig-i386.h, pyconfig-x86_64.h and pick one of them based on preprocessor defines in a small
pyconfig.h wrapper.
Comment 3 Mihai Ibanescu 2006-06-22 17:35:13 UTC 
This has been fixed in rawhide with the split of pyconfig.h into a 32-bit and a
64-bit variant.
Comment 4 Axel Thimm 2006-08-05 10:02:35 UTC 
This fix broke distutils.sysconfig.{get_config_h_filename,parse_config_h}, bug
filed under #201434, because python cannot parse the wrapper properly. In turn
this breaks python packages that want to query pyconfig.h for build flags on
python level, for example bug #201435. There may be more python packages
affected, e.g. all that use pyconfig.h from python level and not C/C++.

I suggest to also patch distutils.sysconfig.get_config_h_filename to return
pyconfig-32.h or pyconfig-64.h respectively. Something like

sed -i -e"s,'pyconfig.h','%{_pyconfig_h}'," Lib/distutils/sysconfig.py
Comment 5 Mihai Ibanescu 2006-08-17 22:19:19 UTC 
Fixed, hopefully for good this time.
Note You need to log in before you can comment on or make changes to this bug.