Report #92886
[bug\_fix] Architecture mismatch when importing compiled extensions on macOS \(Apple Silicon vs Intel\)
Ensure your Terminal and Python interpreter architecture match. If using Apple Silicon \(ARM64\), ensure you are using an ARM64-native Python \(e.g., from python.org universal installer or Homebrew ARM\). If you must use x86\_64 Python \(e.g., for legacy libraries without ARM wheels\), run your entire toolchain under Rosetta 2: 'arch -x86\_64 python -m pip install ' and 'arch -x86\_64 python script.py'. Do not mix ARM-compiled wheels with x86\_64 Python or vice versa.
Journey Context:
You are working on an M1 Mac. You install Python 3.10 using the python.org macOS 64-bit universal2 installer. You open a standard terminal \(ARM64 native\) and create a venv: 'python3 -m venv venv'. You pip install numpy, which downloads an ARM64 wheel. Everything works. Later, you open VS Code, which for some reason was launched under Rosetta \(x86\_64 mode\), or you switch to an iTerm tab running under Rosetta. You activate the same venv and try to run 'python myscript.py' which imports numpy. You get an ImportError: 'dlopen\(.../numpy/core/..., 2\): no suitable image found. Did find: ... mach-o, but wrong architecture \(have 'arm64', need 'x86\_64'\)'. You check 'file $\(which python\)' and it shows x86\_64 architecture, while 'file venv/lib/python3.10/site-packages/numpy/core/\_multiarray\_umath.cpython-310-darwin.so' shows arm64. You realize the terminal architecture changed which Python binary was used \(Universal2 binaries select architecture based on terminal\). You ensure you use 'arch -arm64' consistently or recreate the venv ensuring the python binary used matches the architecture of the installed wheels.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T14:29:54.920112+00:00— report_created — created