libcxx 17 has recently dropped support for macOS<10.13 when building the shared libcxx library (I noted this in https://github.com/conda-forge/libcxx-feedstock/issues/110 when the RFC opened).

As far as I can tell, this is more fundamental than the availability workarounds we do (for building projects on top of libcxx), as it will really become impossible to build (shared) libcxx itself for targets <10.13.

Like for other fundamental toolchain dependencies (like upstream requiring vs2019 vs. vs2017 recently), I don’t think it’s feasible to try to keep patching back in support for older macos versions, as there will be zero coverage upstream and therefore things will bitrot fast.

Seeing that LLVM is our default toolchain on osx (and assuming I’m not overlooking something), I think we’ll have to increase the minimum version to 10.13 at the latest when we switch our default compilers on osx to clang 17 (earliest that could happen would be late 2023; of course we could drag it out for quite a while longer by staying on clang 16 for another year or so afterwards).

PS. It’s worth noting that libcxx had been waiting on chrome to bump their required minimum version to 10.13, which was apparently the last major “holdout” (from the POV of LLVM). So I think end of 2023 would actually a very reasonable timeline to bump to 10.13; at that point 10.12 will have been EOL for 4 years.

FYI: We are not restricted by the xcode version and our builds are completely independent of the macos build image. See https://github.com/conda-forge/conda-forge-ci-setup-feedstock/blob/main/recipe/download_osx_sdk.sh

Newest abseil requires MacOS 10.13 (and fails with 10.9). I’d like to migrate this together with the new libgrpc & libprotobuf, but seeing how widely abseil is used, that’s effectively a conda-forge-wide decision (at least as far as C++ deps are concerned).

I saw that @chenghlee had put up the idea of dropping osx-64 support entirely (in the meeting notes of the last core call, though apparently it wasn’t discussed yet). Given all of the above datapoints (libcxx, clang, abseil, protobuf, C11’s aligned_alloc, how long ago the EOL was, the comparison to the last bump, etc.), is there any serious opposition to just bumping to 10.13?

For now - I will redirect similar questions from our users to this thread,

Please don’t. Ask them to give all of the information asked in https://github.com/conda-forge/google-re2-feedstock/issues/6 and redirect there.

An example feedstock with selectors on compilers and things like compiler('m2w64_c') would be good to check.

thing that breaks us the fastest is GHA/AP removing the last x64 agents for macOS.

AP would likely provide arm64 agents like GHA is doing now which we can use to cross compile for x64 and run tests with rosetta 2 emulation.

I was thinking all migrations.

Please see the ongoing discussion in conda/conda-build#5053

OK, this issue was closed now, meaning we should have a green light to move ahead with the current implementation, which has already been released in conda-build 3.28. 🥳

The main question is now how to introduce {{ stdlib("c") }} across a very large amount of recipes.

PS. Cryptography 42.0 will now (by way of the rust standard library) require 10.12+.

Noticed today that even with a 10.13 deployment target, “10.9” is still encoded in some of the build infra (I presume it’s irrelevant; just mentioning it for completeness):

                                                                                                          HERE
                                                                                                          vvvv
-- Installing: /Users/runner/miniforge3/conda-bld/apache-arrow_1694590793611/work/python/build/lib.macosx-10.9-x86_64-cpython-39/pyarrow/./libarrow_python.dylib
-- Installing: /Users/runner/miniforge3/conda-bld/apache-arrow_1694590793611/work/python/build/lib.macosx-10.9-x86_64-cpython-39/pyarrow/./libarrow_python_flight.dylib
-- Installing: /Users/runner/miniforge3/conda-bld/apache-arrow_1694590793611/work/python/build/lib.macosx-10.9-x86_64-cpython-39/pyarrow/include/arrow/python
-- Installing: /Users/runner/miniforge3/conda-bld/apache-arrow_1694590793611/work/python/build/lib.macosx-10.9-x86_64-cpython-39/pyarrow/include/arrow/python/csv.h
                                                                                                          ^^^^
                                                                                                          HERE

docs here: https://docs.conda.io/projects/conda-build/en/stable/resources/variants.html#appending-to-recipes

See here: https://github.com/conda-forge/conda-forge-ci-setup-feedstock/issues/260

Man you’re a wizard with GitHub search!

Thanks for the kind words! Bit too high a praise for using path:<glob>, but you inspired me to try if multiline regexes work with the new search, and they do! 🤩

So here’s a search for only those feedstocks pinning MACOSX_DEPLOYMENT_TARGET to something <10.13.

OK! So it looks like 10.13 is the minimum. I think we had settled on 10.12 or so a few years ago so that seems fine.

My understanding of what we need to do to make this happen.

• make an announcement (https://github.com/conda-forge/conda-forge.github.io/pull/1993)
• decide how we want to enforce the __osx constraint
• Decide if we will allow folks to set a min version less the global minimum.
  • If yes, do nothing.
  • If no, then we need a minimigrator to adjust / remove any custom minimum pins below 10.13
• adjust ci-setup package to download the right SDK? (it may use whatever is in the pins and so this may not be needed. I need to check.)
• adjust smithy? IDK if we need this or not.
• figure out if there are any finicky builds on osx that need adjusting? I recall some but maybe that is out of date by now.
• patch old builds with 10.9 __osx constraint?
• bump in global pinnings

What else did I miss?

I only meant to say as old as possible. If 10.13 is that number, great!

I didn’t realize you had numbers for all internet users above. Sorry about that.

but I don’t know why it is getting brought up here as it is tangential to the topic of macOS 10.9 support

If we were to drop osx-64 (not my proposal), then obviously this discussion becomes moot, hence the pretty direct relation. In any case, let’s shelve that one, as @chenghlee is clearly not planning that in the short term.

Agree with Matt we should collect data on OS version usage and see what we find

Obviously numbers from our package downloads would be interesting. I already provided some numbers above. 95% of all internet users are on >=10.13, which includes an even longer tail than conda-forge. The fact that chrome dropped support for <10.13 should be a good indicator that even google with all its resources does not see this as worth supporting anymore.

Apple aggressively forces people to upgrade, and we’re talking about moving from something that’s been EOL almost 7 years to something that’s “only” been EOL 3 years. The last upgrade in conda-forge was 7 years ago[^1], which is also staggering.

[^1]: to a version that wasn’t EOL at the time; the equivalent of that today would be 11.0

There’s no reason to leave users on older systems behind if we don’t have to.

There’s ample reasons in this thread already. We’re on a 10 year old SDK that is not just unsupported but now broken on many projects. We’ve managed to extend it way past its shelf life with hooking up our own C++ stdlib, but we’ve reached the end of the road.

Continuing to support <10.13 means we never upgrade abseil anymore, never upgrade LLVM anymore, etc. I have trouble finding neutral words for how bizarre I find this desire to support museum OS versions over current users and packages.

I’d push back on dropping osx-64. It seems premature, but I don’t know why it is getting brought up here as it is tangential to the topic of macOS 10.9 support, which is starting to get pretty old

Agree with Matt we should collect data on OS version usage and see what we find

Without more information there’s no point talking. Please fill out the information requested at https://github.com/conda-forge/google-re2-feedstock/issues/6

This is exactly what I am going to ask my users for when raising similar issues.