Issue 18083: _sysconfigdata.py is installed in an arch-independent directory (original) (raw)

_sysconfigdata.py is installed into prefix/lib/pythonX.Y/sysconfigdata.pywhichisanarchitecture−independentdirectory,asopposedtoapathstartingwithe.g.{prefix}/lib/pythonX.Y/_sysconfigdata.py which is an architecture-independent directory, as opposed to a path starting with e.g. prefix/lib/pythonX.Y/s​ysconfigdata.pywhichisanarchitecture−independentdirectory,asopposedtoapathstartingwithe.g.{libdir}, which is architecture-dependent. But _sysconfigdata.py contains architecture-dependent information, which breaks some installation, specifically Solaris multi-arch.

A fix would be to move it to an architecture-dependent directory, but this probably requires some discussion.

Original question on the mailing list: http://mail.python.org/pipermail/python-list/2013-May/647197.html

I'm looking into creating a 32/64-bit Python (2.x and/or 3.x) package for Solaris. The specificity of that package is that I need to include both 32-bit and 64-bit binaries in it. The exact way in which the 32/64 support is done is described at [1].

There currently is a Python package that I maintain, which is 32-bit only[2].

I have made an attempt to build a 64-bit package, and my findings are that the ${prefix}/lib/pythonX.Y/_sysconfigdata.py file contains system-specific information. Note that it's not ${libdir}/pythonX.Y - that would have worked, because I'm specifying different ${libdir} directories when running the 32-bit and 64-bit builds. The Python installer specifically uses ${prefix}/lib/pythonX.Y. For the most part is fine, because most of files in there are not architecture-specific, and it would be quite good to share them among the 32-bit and 64-bit binaries at runtime. The problem is that some files differ. I've described it some more at [3].

Ideally, I'd make _sysconfigdata.py return/set different values depending on the Python runtime that reads it. Something like:

if we're 64-bit: set values for the 64-bit platform else: set values for the 32-bit platform

It's a similar approach to how we currently handle C header files. See the 'Development packages' section in [1] for more information.

The problem is that it would involve somewhat intrusive patching of the Python source code, and in long term that means maintainability issues.