I intentionally canceled the ARM64 builds on travis to spare credits as they are unrelated to this PR.

Hum, the macos builds are still pending...

And the following issue actions/runner-images#1256 seems to indicate that macos-10.15 is the oldest supported platform.

Maybe we could still find a version of the libomp.dylib file that was built to be compatible with 10.13 (or even older) somewhere?

Alternatively, this SO question https://stackoverflow.com/questions/6591988/best-practice-for-osx-10-x-backwards-compatability seems relevant but I can't find the documentation

The homebrew doc states that 10.9-10.13 is supported on a best effort basis:

https://docs.brew.sh/Installation#2

cibuildwheel should automatically set MACOSX_DEPLOYMENT_TARGET to 10.9 according to https://github.com/joerick/cibuildwheel/blob/master/README.md .

I wonder if we can try to get the bottle built for high_sierra (10.13) and use that in build_tools/github/build_wheels.sh:

wget https://homebrew.bintray.com/bottles/libomp-11.0.0.high_sierra.bottle.tar.gz
brew install libomp-11.0.0.high_sierra.bottle.tar.gz

while keeping gihtub ci at macos-latest.

Maybe we should install libomp using conda-forge instead. It's weird because in the past (on the https://github.com/MacPython/scikit-learn-wheels repo) we used homebrew to install libomp and we did not get this issue.

The version of the macos VM on Azure Pipelines is 10.14:

https://github.com/MacPython/scikit-learn-wheels/blob/master/azure-pipelines.yml#L81

and the script set the deployment target to 10.9 explicitly:

https://github.com/MacPython/scikit-learn-wheels/blob/master/azure/posix.yml#L52

libomp was installed from homebrew as well:

https://github.com/MacPython/scikit-learn-wheels/blob/master/extra_functions.sh

@thomasjpfan your trick seems to work. At least the build completes successfully, and I can install the resulting wheel and run the test on macos 11.1. I don't have an old macos handy unfortunately.

Repeating #19063 (comment) here for visibility.

I tested the fix (via this provided link) on Travis's osx_image: xcode9.4 (macOS 10.13) build environment. The error we were experiencing has gone away.

• Before: https://travis-ci.com/github/neuropoly/spinalcordtoolbox/jobs/464176777#L1073-L1090
• After: https://travis-ci.com/github/neuropoly/spinalcordtoolbox/builds/210436629#L1095

@thomasjpfan @alfaro96 @jeremiedbb ok for merge on your side?

Actually since high sierra is 10.13, maybe we should set the MACOSX_DEPLOYMENT_TARGET to "10.13" for the [cd build] environment and make sure that the generated wheels have 10_13 instead of 10_9 in their name + metadata.

I don't think homebrew makes it possible to get 10.9 compatible version of libomp.

@thomasjpfan how did you find the URL of the high sierra (10.13) bottle for libomp? I am wondering if we can find a mavericks (10.9) version of the same package.

Actually since high sierra is 10.13, maybe we should set the MACOSX_DEPLOYMENT_TARGET to "10.13" for the [cd build] environment and make sure that the generated wheels have 10_13 instead of 10_9 in their name + metadata.

I don't think homebrew makes it possible to get 10.9 compatible version of libomp.

I have checked the official libomp formulae and the oldest version is high_sierra. Therefore, maybe it is worth it to set the MACOSX_DEPLOYMENT_TARGET to "10.13".

@thomasjpfan how did you find the URL of the high sierra (10.13) bottle for libomp? I am wondering if we can find a mavericks (10.9) version of the same package.

The URLs are available here: https://formulae.brew.sh/api/formula/libomp.json.

Ok thanks, let me try to set the deployment target to 10.13 then.

Related: matthew-brett/delocate#56

From the logs of the CPython 3.8 macos build:

Repairing wheel...
  
  + delocate-listdeps /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibuildwheelcoccs2t7/built_wheel/scikit_learn-1.0.dev0-cp38-cp38-macosx_10_13_x86_64.whl && delocate-wheel --require-archs x86_64 -w /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibuildwheelcoccs2t7/repaired_wheel /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibuildwheelcoccs2t7/built_wheel/scikit_learn-1.0.dev0-cp38-cp38-macosx_10_13_x86_64.whl
  /usr/local/Cellar/libomp/11.0.0/lib/libomp.dylib

and later:

pip install /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibuildwheelcoccs2t7/repaired_wheel/scikit_learn-1.0.dev0-cp38-cp38-macosx_10_13_x86_64.whl
  Processing /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/cibuildwheelcoccs2t7/repaired_wheel/scikit_learn-1.0.dev0-cp38-cp38-macosx_10_13_x86_64.whl

So it looks like it's working as expected: distutils is taking the MACOSX_DEPLOYMENT_TARGET environment variable into account to set the wheel metadata.

I still do not understand why we did not face the problem when releasing 0.23.2. Maybe the default homebrew bottle for libomp was still compatible with 10.9 at the time.

I tested the artifacts from the bbfed0c build on travis osx 10.13 here: thomasjpfan/sklearn_osx_travis_test#1

Thanks for testing @thomasjpfan. Shall we merge?