Bad CPU Type on Apple Silicon #5640
Comments
|
This one's caused by some of our utility code still living in simpler times where pyinstaller/PyInstaller/compat.py Lines 489 to 505 in 227eac1 So we end up trying to run python with x86_64 arch, which does not work on M1 unless it happens to be If you need quick fix for that, you can try forcing py_prefix = ['arch', '-' + platform.machine()] |
|
But do note that freezing on pure |
|
I think we probably ought to rename our bootloader directories whilst we're at it in that case. Linux is also now on |
True, that should be cleaned up at some point as well. But it'll require changes in both bootloader's waf script and python-side code. I think currently, when compiling natively for those platforms on linux, the directories actually get named correctly. (But if you try to force arch manually, you hit a check that prevents you from using anything else than '32bit' or '64bit'). For macOS specifically, if we're going with |
|
Fortunately code frozen on an i386 under Catalina still runs in Big Sur on both ARM and Intel hardware. I think for the moment I'll continue to build on i386 hardware as this particular program is used widely in our organization. Is the scope of work to repair this such that I should plan to keep an i386/catalina machine for a long time? I only ask because I'll have to fight my IT department a bit to step out of the mandatory upgrades we roll out in July. |
|
I assume you mean x86_64 instead of i386? As far as I know, Catalina dropped support for 32-bit. I personally think that at the moment, creating an x86_64 build is the safest way to ensure that your application will run everywhere. Because it will run on current Intel hardware, and on Apple M1 (with Rosetta translation). If you build using We're planning to enable So I think what we'll do is to build |
|
So long story short, you'll probably want to keep x86_64 mac around, unless you're going to upgrade all your users to M1. And if the question was Catalina vs. Big Sur, the answer is kind of the same. If all your users will receive mandatory upgrade to Big Sur, then you can probably move your build environment to Big Sur as well. Otherwise, it might be safer to stick with Catalina unless you ensure that the versions of python packages installed in Big Sur build environments are also compatible with Catalina. |
|
@rokm |
|
I'm using the latest pyinstaller version on a new Mac mini: % pyinstaller --version
4.3
% python
Python 3.9.2 (default, Jun 25 2021, 15:55:33)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
% sw_vers
ProductName: macOS
ProductVersion: 11.2.2
BuildVersion: 20D80Building with pyinstaller is successful: % pyinstaller test.spec --clean
19 INFO: PyInstaller: 4.3
19 INFO: Python: 3.9.2
25 INFO: Platform: macOS-11.2.2-arm64-arm-64bit
27 INFO: UPX is not available.
...
13053 INFO: Building EXE from EXE-00.toc completed successfully.But similar problem when I try to run the executable: % ./dist/test
zsh: bad CPU type in executable: ./dist/testI'm guessing I'm missing something obvious. Am I simply running it incorrectly? |
|
@mbanders You need to use |
|
@rokm Thanks ok I now uninstalled pyinstaller 4.2, and instead git cloned and installed pyinstaller from source. Unfortunately now building fails: % pyinstaller --clean test.spec
19 INFO: PyInstaller: 5.0.dev0
19 INFO: Python: 3.9.2
24 INFO: Platform: macOS-11.2.2-arm64-arm-64bit
...
14719 INFO: Converting EXE to target arch (arm64)
Traceback (most recent call last):
File "/Users/mianderson/Documents/.virtualenvs/first/bin/pyinstaller", line 33, in <module>
sys.exit(load_entry_point('pyinstaller==5.0.dev0', 'console_scripts', 'pyinstaller')())
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/__main__.py", line 126, in run
run_build(pyi_config, spec_file, **vars(args))
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/__main__.py", line 65, in run_build
PyInstaller.building.build_main.main(pyi_config, spec_file, **kwargs)
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/building/build_main.py", line 758, in main
build(specfile, kw.get('distpath'), kw.get('workpath'), kw.get('clean_build'))
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/building/build_main.py", line 705, in build
exec(code, spec_namespace)
File "test.spec", line 29, in <module>
exe = EXE(pyz,
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/building/api.py", line 524, in __init__
self.__postinit__()
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/building/datastruct.py", line 159, in __postinit__
self.assemble()
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/building/api.py", line 708, in assemble
osxutils.binary_to_target_arch(self.name, self.target_arch,
File "/Users/mianderson/Documents/.virtualenvs/first/lib/python3.9/site-packages/pyinstaller-5.0.dev0-py3.9.egg/PyInstaller/utils/osx.py", line 334, in binary_to_target_arch
assert target_arch in archs, \
AssertionError: Bootloader EXE is incompatible with target arch arm64 (has arch: x86_64)! |
And recompile the bootloader. |
|
Right, I forgot to mention that you need to rebuild the bootloader yourself. |
|
Thanks! Rebuilding the bootloader led to success. For any future reader here: |
Description of the issue
PyInstaller reports
Bad CPU type in executablewhen run on Apple M1 Silicon (Big Sur) at various points during building and fails to build executable.Context information (for bug reports)
pyinstaller --version:4.25.0.dev0: Same resultsMake sure everything is packaged correctly
--noupxor setupx=Falsein your .spec-file--debugtopyi-makespecorpyinstalleror useEXE(..., debug=1, ...)in your .spec file.A minimal example program which shows the error
Stacktrace / full error message of minimal example:
A minimal example does not fail to build, but does generate errors
Output of executable:
Output when building full program:
The text was updated successfully, but these errors were encountered: