Python 3.x built for ppc+ppc64 errs on: No module named 'msvcrt', '_posixsubprocess'

[barracuda156]

BPO	47240
Nosy	@ronaldoussoren, @ned-deily, @barracuda156

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-04-06.11:08:59.345>
labels = ['OS-mac', 'build', '3.8', '3.9', '3.10']
title = "Python 3.x built for ppc+ppc64 errs on: No module named 'msvcrt', '_posixsubprocess'"
updated_at = <Date 2022-04-06.14:37:24.268>
user = 'https://github.com/barracuda156'

bugs.python.org fields:

activity = <Date 2022-04-06.14:37:24.268>
actor = 'ronaldoussoren'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['macOS']
creation = <Date 2022-04-06.11:08:59.345>
creator = 'barracuda156'
dependencies = []
files = []
hgrepos = []
issue_num = 47240
keywords = []
message_count = 2.0
messages = ['416857', '416873']
nosy_count = 3.0
nosy_names = ['ronaldoussoren', 'ned.deily', 'barracuda156']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue47240'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[barracuda156]

While adding definitions for additional universal binary option (ppc+ppc64) is rather straightforward (following already existing examples in the source code), and Python 3.x after patching do build as universal for named two arch, trying to install any python modules fail on the following:

--->  Building py39-curl
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 73, in <module>
    import msvcrt
ModuleNotFoundError: No module named 'msvcrt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-curl/py39-curl/work/pycurl-7.44.1/setup.py", line 11, in <module>
    import glob, os, re, sys, subprocess
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 78, in <module>
    import _posixsubprocess
ModuleNotFoundError: No module named '_posixsubprocess'
Command failed: /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 setup.py docstrings
Exit code: 1

Separately both ppc and ppc64 are totally fine, they build and work, but not together.
At the same time python27 after a similar patch builds as universal (ppc+ppc64) and works normally. So the problem somehow arises on 3.x versions.

P. S. I am aware that Darwin PowerPC is an interest for very few users and even fewer developers, so I do not expect the upstream to fix this in the code.
However I will greatly appreciate any advice which may point to what I should fix on my end. If I can fix Pythons for ppc+ppc64, it will benefit Macports users, among whom there are people using Leopard actively.
Relevant ticket on Macports: https://trac.macports.org/ticket/64916
Such fix may also benefit Linux PPC users on G5 machines.

I request moderators not to dismiss & close the issue, if possible. We don’t have Python experts on Macports, and all fixes for PowerPC are done by very few enthusiasts.

[ronaldoussoren]

The problem you should look into is why the _posixsubprocess doesn't build, the message about msvcrt is a red herring due to the way subprocess.py is structured.

Also compare the pyconfig.h files created for the two single architecture builds, maybe there are differences in detected features for the two architectures (other than CPU differences, there's a pymacconfig.h files that sets the correct values for sizes of basic types).

That said, I won't be debugging this issue myself. MacOS on PowerPC is by now a thing of the past and IIRC the last time I had access to a 64-bit PPC machine was before GUI code would run properly in PPC64 mode.

[barracuda156]

@ronaldoussoren Thank you. I was able to fix it via modifying how the port is being built and using lipo. Perhaps far from being the optimal solution, but I got Pythons 3.x as universal now.

[ronaldoussoren]

Great to hear.

[erlend-aasland]

Can this be closed?

[barracuda156]

Can this be closed?

@erlend-aasland Yes, sure. Thank you.

If I figure out later on how to fix ppc+ppc64 build within Python code itself, I will submit a PR. My present solution involves Macports infrastructure (muniversal PG + portfile code), so it is not portable outside Macports.