"not a supported wheel on this platform" failure during test phase using Github Actions on macOS-latest

[urschrei]

Description

I'm using cibuildwheel 2.2.2 to build my wheel using Github Actions.

• The wheel has a C extension which has been built on GH Actions using the same macos-latest image
• I'm building on Linux and macOS on CI
• cibuildwheel correctly builds, repairs, and tests the wheel on linux
• I can build the wheel on my local machine (Intel Mac, Monterey 12.0.1) using python -m pip wheel
  • Delocate runs successfully on my local machine
  • I can install the repaired wheel in a clean virtualenv locally, and tests pass
• I'm specifying cp3{7, 8, 9, 10}-macosx_x86_64 wheels to be built using cibuildwheel
• cibuildwheel appears to correctly build and repair the wheel on CI (see log)
• The original and repaired wheel both seem to have the correct name:
  • convertbng-0.6.35-cp37-cp37m-macosx_11_0_x86_64.whl
• However, the "test" phase fails with "not a supported wheel on this platform" when trying to install the wheel that's been repaired.

Build log

https://github.com/urschrei/convertbng/runs/4311025782?check_suite_focus=true

CI config

https://github.com/urschrei/convertbng/blob/master/.github/workflows/wheels.yml

[henryiii]

Operating System
  Mac OS X
  10.15.7

You really should target 10.12 or maybe 10.14, not 11. Especially when building on 10.15. ;)

[urschrei]

Is the usual way to do this by setting CIBW_ENVIRONMENT: MACOSX_DEPLOYMENT_TARGET=10.12?

cibw has picked it up, but the build doesn't seem to have taken account of it.

[urschrei]

Switching to a macOS 10.11 runner on GH Actions builds convertbng-0.6.35-cp37-cp37m-macosx_11_0_x86_64.whl which then also fails with the same error: https://github.com/urschrei/convertbng/runs/4312494213?check_suite_focus=true#step:7:200

This is very confusing.

[henryiii]

My guess is you might be getting something 11+ in the dependencies, maybe from Rust? I'd set MACOSX_DEPLOYMENT_TARGET=10.12 everywhere, just in case. I've put up a few changes that might help in a PR.

Oh, interesting, maybe you are bundling an invalid binary in the Rust process?

[urschrei]

I'm just rebuilding the binary on 10.11 on CI, just to be sure…

[henryiii]

This looks suspect:

cp ${{ env.wheelname }}/*.dylib wheelhouse

Why are you dumping a library into the wheelhouse?

This thing is "liblonlat_bng.dylib" (plus a header).

[henryiii]

(this happens before cibuildwheel runs)

[urschrei]

I've switched the Rust dylib to build on 10.11 (same GH Actions image):

otool -l output for liblonlat_bng.dylib 0.6.14:

cmd LC_BUILD_VERSION
    cmdsize 32
    platform 1
    minos 11.0
    sdk 12.0
    ntools 1
    tool 3
    version 711.0

I've also removed that suspect cp … wheelhouse step, and am explicitly re-running Cython during the wheel build to regenerate cutil.c (The Linux build still completes following this modification). The error is the same, even though the wheel name is now convertbng-0.6.35-cp37-cp37m-macosx_11_0_x86_64.whl: https://github.com/urschrei/convertbng/runs/4313210629?check_suite_focus=true#step:6:187

[henryiii]

minos 11.0 == min OS 11.0.

macOS release over the last 9 years are 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.15, 11.0, 12.0 (one per year)

You need to target something older using MACOSX_DEPLOYMENT_TARGET. Setting the build image to macOS-11 might not even have any affect at all, since macos-latest sometimes means 11, and sometimes means 10.15 (they are transitioning it now). The version of macOS you build on shouldn't matter, you should always set MACOSX_DEPLOYMENT_TARGET at what your are targeting for a minimum. You can't set it lower than 10.9, so that's a good place to start. 10.10, 10.12, and 10.14 are some other common settings based on new features added (10.14 if you use lots of C++17, for example).

[urschrei]

otool output on my Rust dylib with your suggested fix:

cmd LC_VERSION_MIN_MACOSX
    cmdsize 16
    version 10.9
    sdk 12.0

And the macOS convertbng builds now pass. Rust used to set 10.7 as the minimum on x86_64, and 11.0 only on aarch64 but I wonder whether that's changed recently – in any case, thank you very much for your help!