+++ This bug was initially created as a clone of Bug #201434 +++
Description of problem:
/usr/include/python2.4/pyconfig.h is now a wrapper for 32/64 bit sub-includes.
This breaks the usual query mechanism for extracting python build flags.
Version-Release number of selected component (if applicable):
python-2.4.3-14
How reproducible:
always
Steps to Reproduce:
1.config_h = sysconfig.get_config_h_filename()
2.config_h_vars = sysconfig.parse_config_h(open(config_h))
3.
Actual results:
{}
Expected results:
{'STRICT_SYSV_CURSES': "/* Don't use ncurses extensions */", 'HAVE_SELECT': 1,
'HAVE_ST_BLOCKS': 1, [...]
Additional info:
o Breaks builds of smart package
o One can argue that the bug is in the implementation of parse_config_h, which
should be able to descend into further included files. OTOH it would then need
to understand nested conditionals, too.
o maybe the 32/64 bits switch should be performed already on
get_config_h_filename level? E.g. get_config_h_filename should return
pyconfig-32.h and pyconfig-64.h respectively?
Thanks!
-- Additional comment from Axel.Thimm@ATrpms.net on 2006-08-05 06:07 EST --
Turns out this is due to the fix for multilib -devel support in bug #139911
comment 2. This fix only considered C/C++ consumers of pyconfig.h. python's
querying mechanism needs to be redirected, too, by patching
get_config_h_filename. A simple untested specfile fix is in bug #139911 comment 4.
-- Additional comment from misa@redhat.com on 2006-08-17 18:18 EST --
Fix (based on your suggestion) included in python-2.4.3-15 - thanks!

I verified that this is fixed in beta2, thanks!
But I cannot close this bug, it says:
"You tried to change the Status field from MODIFIED to CLOSED, but only the owner
or submitter of the bug, or a sufficiently empowered user, may change that
field."
Well, I'm the submitter, but anyway, please close this bug whoever is
"sufficiently empowered". :)