This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author automatthias
Recipients automatthias
Date 2013-05-28.16:34:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za>
In-reply-to
Content
_sysconfigdata.py is installed into ${prefix}/lib/pythonX.Y/_sysconfigdata.py which is an architecture-independent directory, as opposed to a path starting with e.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.
History
Date User Action Args
2013-05-28 16:34:53automatthiassetrecipients: + automatthias
2013-05-28 16:34:53automatthiassetmessageid: <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za>
2013-05-28 16:34:53automatthiaslinkissue18083 messages
2013-05-28 16:34:53automatthiascreate