Red Hat Bugzilla – Bug 139911
libxml failes to compile with -m32: LONG_BIT complaint in pyport.h
Last modified: 2007-11-30 17:10:55 EST
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.
For a work-around, can configure with: --without-python
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.
This has been fixed in rawhide with the split of pyconfig.h into a 32-bit and a 64-bit variant.
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
Fixed, hopefully for good this time.