| 11 Apr 2024 |
 Randy Eckenrode | In reply to @jonringer:matrix.org
10.14 is kind of "big" for macOS, C++14 (IIRC), and a few other tooling improvements landed in that release We use our own libc++, so even 10.12 has whatever the latest is. This ld64 update would bring Darwin up to the version of ld-classic shipped in Xcode 15.3. The cctools update handles signatures better. If it’s a linker-signed ad hoc signature, strip&c will update the signature automatically without a hook or wrapper. | 16:52:12 |
 Weijia | In reply to @reckenrode:matrix.org
It’s not an SDK change. That will come post 24.05. The updated cctools and ld64 have a hard requirement on using libdispatch APIs that are only available in 10.14. They can be built with the 11.0 SDK and a 10.14 deployment target in the meantime until the default SDK is changed. Wait, with the 11.0 SDK on x86_64-darwin? | 16:52:18 |
| Randy Eckenrode | In reply to @wegank:matrix.org
Wait, with the 11.0 SDK on x86_64-darwin? Yes. overrideSDK can build with one SDK and set an earlier deployment target. Fixing that was one of the goals of the rewrite in staging. | 16:53:10 |
| Randy Eckenrode | Darwin already has two other packages in the bootstrap that require the 11.0 SDK to build: psutil and libuv. cctools and ld64 would be the first to require a newer version at runtime. | 16:54:07 |
 Vladimír Čunát | You don't plan dropping x86_64-darwin anytime soon, I guess? | 16:58:39 |
 jonringer | Just to reason about time left, breaking changes to staging need to land by May 1st, to allow for some stabilization iterations before cutting the release. If we are signing up for a blocker, it should be able to fit within that time period (or very close to that time period). | 17:00:56 |
| jonringer | I'll defer to Weijia and Randy Eckenrode on the judgement call :) | 17:02:35 |
| Weijia | In reply to @wegank:matrix.org
I think I'd ask for an x86_64-darwin jobset (and a public announcement) before approving a PR on this, even if it only contains a treewide substitution of "10.12" by "10.14" And I intend to postpone this change to early June, to give macOS 10.12 and 10.13 users a six-month grace period | 18:25:24 |
| Weijia | Announcing an immediate end of life for them is too difficult for me... | 18:25:47 |
 adamcstephens | Macs that were built in 2012 can upgrade to 10.14/10.15.... | 18:29:53 |
| adamcstephens | we've almost doubled Apple's support for these systems, and at what point are we encouraging bad security behavior by continuing to offer support for them? | 18:36:14 |
| Randy Eckenrode | In reply to @vcunat:matrix.org
You don't plan dropping x86_64-darwin anytime soon, I guess? No, both would still be supported. This is just about not being able to link packages on <10.14. | 18:37:59 |
| Vladimír Čunát | OK. I meant it only as a loosely related, and half-joking. | 18:39:00 |
| adamcstephens | so they could consume cached packages, but not build (link) them themselves? | 18:39:01 |
| Randy Eckenrode | In reply to @wegank:matrix.org
And I intend to postpone this change to early June, to give macOS 10.12 and 10.13 users a six-month grace period So targeting 24.11, essentially? (Though given that unstable is the default, it’s essentially effective immediately.) | 18:39:28 |
| Randy Eckenrode | In reply to @adam:robins.wtf
so they could consume cached packages, but not build (link) them themselves? Correct. The linker uses a ton of GCD stuff that’s only available in 10.14+. It may be possible to build libdispatch from source or user a portable replacement. I haven’t looked into those in detail yet. | 18:41:20 |
