-
Notifications
You must be signed in to change notification settings - Fork 239
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
Testing universal2 wheel on arm64 macOS cp38 runner result in not a supported wheel on this platform
#1767
Comments
not a supported wheel on this platform
not a supported wheel on this platform
not a supported wheel on this platform
As I investigate further, it seems like the problem is caused by x86_64 (non-universal2) version of python 3.8 running on arm64 macOS, which has bug in checking wheel tag such that This seems to be caused by the same issue as #1603 and I can confirm that adding Should we add Other hacks, workarounds:
|
Nice work debugging this. So you'll be hitting this error due to these lines in your config: Is there a specific reason you set MACOSX_DEPLOYMENT_TARGET to 11.0 on this build? It's 10.15 on the x86_64 one. macOS 11.0 is the first to support arm64, so it's implicit that you'd need 11.0 or later on arm64. (Also, just FYI, unless there's something going on here that I've missed, you shouldn't need to set As for the broader issue, I think you're right, we should set SYSTEM_VERSION_COMPAT=0 when testing universal2 Python 3.8 wheels on x86_64. Otherwise, as you have discovered, it's not possible to set MACOSX_DEPLOYMENT_TARGET to anything greater than 10.16. I don't think that Python 3.9+ would need this though, because they'll be built with a newer SDK, so macOS won't do any version-compat shimming. I see that you only had the issue with 3.8, so I guess that's correct. |
Fortunately no, so I can just set it back to 10.15 to avoid this problem. I originally thought that the targets should match for both the arm64 and x86_64 part of universal2 wheel. Turns out this is not necessary.
This is because I need to set x86_64 deployment target to 10.15, as the C++ code I am compiling requires it. The default 10.9 won't work for me.
Opened a PR for this: #1768 |
For reference, this is really a bug in pip that we're working around, ref pypa/pip#11715 |
To be clear, this is a dupe of #1603 , i'm just more inclined to do something about it given that a fix in pip doesn't appear to be imminent... |
* Set SYSTEM_VERSION_COMPAT=0 during pip install on macos (#1767) * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Only set SYSTEM_VERSION_COMPAT=0 for CPython 3.8 * Set SYSTEM_VERSION_COMPAT=0 for CPython <= 3.8 * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Update cibuildwheel/macos.py Co-authored-by: Joe Rickerby <joerick@mac.com> * Update cibuildwheel/macos.py Co-authored-by: Joe Rickerby <joerick@mac.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Joe Rickerby <joerick@mac.com>
My builds are producing warnings that link to this issue. (sample build) Is any action required? (If not, is the log message necessary?) Does this mean that users of my package will have to use SYSTEM_VERSION_COMPAT=0 for py38 on macos? Note that I am not setting MACOS_DEPLOYMENT_TARGET unless cibuildwheel is doing it for me somewhere. |
Relevant issue: pypa/cibuildwheel#1767.
Description
Currently, to test a wheel, wheels are first installed with pip. On arm64 macOS github runner (
macos-14
), wheels are installed witharch -x86_64 pip install ...
. This results inERROR: xxx_universal2.whl is not a supported wheel on this platform.
.On my local M1 macmini, I am able to recreate the issue by:
python3.8 -m pip install apngasm_python-1.2.3-cp311-cp311-macosx_11_0_universal2.whl
.If I rename the problematic wheel name to
-macosx_10_9_universal2.whl
, the problem does not occur. This does not make sense as we are testing on macos-14, which is much newer than macos10.9
or11.0
.This problem does not occur for universal2 python versions (i.e. python >3.8).
Relevant issue: #1746
You can download sample universal2 wheels from artifact of this run (https://github.com/laggykiller/apngasm-python/actions/runs/8063189658), or directly down here:
apngasm_python-1.3.0-cp38-cp38-macosx_11_0_universal2.whl.zip
apngasm_python-1.3.0-cp39-cp39-macosx_11_0_universal2.whl.zip
apngasm_python-1.3.0-cp310-cp310-macosx_11_0_universal2.whl.zip
apngasm_python-1.3.0-cp311-cp311-macosx_11_0_universal2.whl.zip
apngasm_python-1.3.0-cp312-abi3-macosx_11_0_universal2.whl.zip
(
.zip
was added to the end of whl file name end so that github allow me to upload it. Just remove.zip
extension from the file name after downloading.)Build log
https://github.com/laggykiller/apngasm-python/actions/runs/8061744757/job/22020065912#step:4:1347
EDIT: I have tried with cibuildwheel master branch, and the problem still exists: https://github.com/laggykiller/apngasm-python/actions/runs/8074988563/job/22061164760#step:4:1419
CI config
https://github.com/laggykiller/apngasm-python/blob/c046caa64b633fe1cc957f67fd4fbc0f6abd7b40/.github/workflows/build.yml
The text was updated successfully, but these errors were encountered: