Bug 139911 - libxml failes to compile with -m32: LONG_BIT complaint in pyport.h
libxml failes to compile with -m32: LONG_BIT complaint in pyport.h
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Brock Organ
: Reopened
Depends On: 192747
Blocks: 201434
  Show dependency treegraph
 
Reported: 2004-11-18 14:06 EST by Ben Greear
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.4.3-15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-17 18:19:19 EDT
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 Ben Greear 2004-11-18 14:06:14 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.
Comment 1 Ben Greear 2004-11-18 14:16:12 EST
For a work-around, can configure with: --without-python
Comment 2 Jakub Jelinek 2004-11-18 15:04:07 EST
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 13:35:13 EDT
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 06:02:35 EDT
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 18:19:19 EDT
Fixed, hopefully for good this time.

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