kivy: Setup.py missing osx_arch == "arm64" test, to build natively for Apple Silicon

Software Versions

Python: 3.8.6
OS: macOS 11.1
Kivy: 2.0.0
Kivy installation method: Compile from source

Describe the bug Running “make” in a native Darwin arm64 environment (not Rosetta 2) produces an x86_64 build on an M1 Mac. This can be verified with “lipo -archs”. As a result, any other arm64 packages that use kivy won’t run natively: “mach-o, but wrong architecture”

However, setup.py is already completely capable of building for arm64. I verified this by very crudely search-replacing the two instances of where ARCH is set to x86_64; I simply changed those to arm64, for example:

# Detect 32/64bit for OSX (http://stackoverflow.com/a/1405971/798575)
if sys.platform == 'darwin':
    if sys.maxsize > 2 ** 32:
        osx_arch = 'arm64'
    else:
        osx_arch = 'arm64'

and so on. Originally osx_arch was set to either i386 or x86_64.

Yes, that’s a horrible way to “fix” it! But after this quick edit, running “make” works and it’s an arm64 build. The resulting build works too, I tested by running “katrain”, which uses kivy. (The motivation for me to patch this for myself was to run katrain.)

How to fix setup.py properly for macOS/arm64

Unfortunately I’m not much of a developer to propose a proper patch, but it looks like it’s just few modifications to setup.py to get it going. There’s an if/else test between i386 and x86_64, but the third and missing match for Darwin should be “arm64”. This needs to be done in two places. Search for these:

elif platform == 'darwin':
...
# Detect 32/64bit for OSX

I can test the patched setup.py on an M1 Mac if someone has time to fix this for the next dot release.

(First message in Github btw. Yay.)

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 20 (9 by maintainers)

Most upvoted comments

@tshirtman it is supported unless someone declares otherwise and shows something to prove it.

What I know is that KaTrain depends on kivy and I haven’t observed any hiccups with a so-called “vanilla installation”, that is, after reinstalling the latest homebrew, kivy-2.1.0.dev0, and katrain-1.7.4, as per their individual instructions and auto-installed dependencies, all native arm64. I did not have to do any wizardry via .zshrc or environment variables to make it work.

Thank you and @matham for picking this up and getting it done. 🙏

> brew --version
Homebrew 2.7.7

> python3 --version
Python 3.9.1

> pip3 list | grep Kivy
Kivy        2.1.0.dev0

katrain-kivy-m1

vividfog on Jan 29, 2021

@matham good news. Since things were broken in strange ways described above, and since @kentdorsey had success starting from a clean slate, I did the same. Wiped out homebrew and everything it provided, including python3 and pip3 modules. Started over.

And suddenly katrain, which uses Kivy, works on my M1. I’ve got no more issues to report on M1 for now. This isn’t a big test case, but it’s an end to end test case and so far so good.

I suspect this had something to do with being an early adopter of arm86 Homebrew. I installed it in December, as soon as there was something to install. Perhaps something was displaced and later brew updates didn’t improve the situation. But no way to conclude one way or another.

vividfog on Jan 28, 2021

Great!

I have only one remaining concern, but i think we’ll learn soon enough if that’s the case, and i assume it would be a rare one. I think it’s possible to have a 32 bit python on an x86_64 osx python, and i think in this case we would now build a version incompatible with the installed python, i don’t have a mac machine to try, and i think you don’t have a mac fit to test that possibility, so no worries. Thanks for confirming it works 😃.

tshirtman on Jan 23, 2021

The resulting arm64 build works to the extent I can test it, which is simply by running katrain. It does run, and the architecture errors mentioned in sanderland/katrain#331 are gone. The top bar of the katrain UI is missing, but that’s a whole another topic.

vividfog on Jan 23, 2021