-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"universal2" and alternate deployment target on macOS #108
Comments
Thanks for reporting. If you are able to find the time, a PR to help with this would be very much appreciated. I took a quick look just now and it looks like upstream support is possible; we'd probably need to build both targets separately and then invoke macOS sdk tools to build the final library. I'm inferring that from BurntSushi/ripgrep#1737 |
Also see PyO3/maturin#405 |
This was referenced Feb 14, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Platform: macOS, in particular M1 systems.
These systems can run both arm64 (native) and x86_64 (in emulation) code, with per process selection using the "arch" command.
For C extensions it is possible to build both architectures on an M1 system (basically a form of cross compiling), including merging code for the two architectures in a fat binary ("Universal 2" in Apple-speak).
setuptools_rust will currently always build arm64 code only, even if python was started in x86_64 mode (e.g.
arch -x86_64 python3.9 setup.py build_ext
).It would be nice if setuptools_rust were able to build "universal2" wheels.
An related to this: for C extensions Python by default builds extension that work on the deployment target used for the python binary. It might be necessary to enhance setuptools_rust to do something similar.
BTW. I hope to have some time to work on a PR in the near future.
The text was updated successfully, but these errors were encountered: