http://www.mail-archive.com/turbo...@googlegroups.com/msg00037.html
But it kind of died with this, well, um,
go-to-comp.lang.python-and-figure-it-out-there advice. Google has no
record of anyone bringing this up on comp.lang.python. I'd do it, but
I feel utterly unqualified to do so. Mandriva is the number 2 Linux
distro[1] and it'd be a shame to have turbogears not working on it.
What can I do to help? If somebody gives me the right questions to
ask, I don't mind asking them on comp.lang.python or anywhere else for
that matter.
Thanks,
Bryan
Actually, Robert Kern and others explained the problem to you, and
pointed you to both Mandriva and to the author of cElementTree.
Reading the thread above I see that it was pointed out that
cElementTree's "setup.py" checks for HAVE_MEMMOVE in the standard
"/usr/include/python2.4/pyconfig.h" file, but your distribution
replaces the standard "pyconfig.h" with some kind of redirection
header.
Ergo, Mandriva has a broken Python installation, because it doesn't
have the configuration information in the standard "pyconfig.h" where
it belongs.
I don't think you can say that cElementTree is broken, just because it
doesn't assume that some guy making a Linux distribution thinks they
can screw around with the contents of pyconfig.h and not break Python
extension modules.
File a bug report with Mandriva, its Python installation is broken.
You can also tell the cElementTree author about the problem, but it's
not reasonable to expect him to be able to fix it. "pyconfig.h" is
supposed to have constants in it, not a bunch of #include's and
#ifdef's to figure out what the constants should be.
As I understand it, the correct way for Mandriva to handle
multi-architecture support for Python is to build with a different
"exec prefix" for each architecture. This should automatically takes
care of having different architectures' "pyconfig.h" files come from
different locations. If it doesn't, then that's a Python build process
bug. :)
That's not the issue. It's that some setup scripts for Python
extensions parse the *contents* of pyconfig.h (as opposed to
interpreting them via the C preprocessor), since in a standard Python
installation the constants will be *there*.
Since Python already has a standard way to deal with multi-architecture
builds, it's not reasonable to expect extension developers to
defensively program for the possibility that some distribution might
decide to redefine Python's installation structure in some arbitrary
way -- that is, a way that's outside the normal Python-provided
mechanisms for such customizations (e.g., sys.exec_prefix).