Report #78822
[bug\_fix] ImportError: mach-o file, but is the wrong architecture \(Apple Silicon\)
Recreate the virtual environment forcing the specific architecture: \`arch -x86\_64 python3 -m venv .venv\` for Rosetta, or ensure you install native arm64 wheels. Root cause: On Apple Silicon \(M1/M2\), Python can run under Rosetta 2 \(x86\_64\) or natively \(arm64\). If you install a package \(e.g., via pip\) using an x86\_64 Python but then try to import it from a native arm64 Python \(or vice versa\), the dynamic linker cannot load the compiled extension \(\`.so\` files\) due to architecture mismatch.
Journey Context:
You're on an M1 Mac \(Apple Silicon\) with Python 3.9 installed via Homebrew \(native arm64\). You create a venv and \`pip install pandas\`. It works. Then you need to use an older version of \`pyobjc\` for a specific automation script. You install it, but when you \`import Foundation\`, you get \`ImportError: dlopen\(.../Foundation.so, 0x0002\): tried: '...' \(mach-o file, but is the wrong architecture\)\`. You check \`file $\(which python\)\` and it shows \`arm64\`. You check the failing \`.so\` file with \`file\` and it shows \`x86\_64\`. You realize you previously installed this package using a Python interpreter running under Rosetta 2 \(perhaps via an old virtual environment or system Python\), or you downloaded an x86\_64 wheel. The arm64 Python cannot load the x86\_64 compiled library. You deactivate the venv, recreate it explicitly forcing x86\_64 architecture with \`arch -x86\_64 python3 -m venv .venv\_x86\` \(if you must use the old library\), install the package there, and it works under Rosetta. Alternatively, you find a native arm64 wheel for the package, delete the venv, recreate a native one, and install the correct architecture wheel.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T14:53:59.505619+00:00— report_created — created