Update macOS SDK

[r-burns]

I'm seeing a growing number of failures on hydra for packages requiring the 10.13 SDK on macOS. What is the timescale on a possible update, and what would that involve? Alternatively, would there be some way to build certain packages against the 10.13 SDK while keeping the default stdenv and majority of packages 10.12-compatible?

Related:
#99133 (folly)
#101125 (apk-tools)
#97479 (various)

[prusnak]

According to https://en.wikipedia.org/wiki/MacOS_version_history#Releases

• macOS 10.12 was EOL on October 2019
• macOS 10.13 will be EOL on November 30, 2020

So I guess ditching 10.12 is fine

[siraben]

In general how long are we comfortable using EOL'd SDKs? Are there security implications?

Related:
#90273 (tintin)
#73744 (closed PR updating SDK to 10.13)

[siraben]

I located the URL for the 10.13 SDK, http://swcdn.apple.com/content/downloads/50/15/041-91747-A_WICZE7RNVZ/rayjnqf847xflt3tan8o8agod67eq88cav/DevSDK_macOS1013_Public.pkg

[abathur]

@LnL7 @thefloweringash Not sure who all should be in the loop here, but I saw a notification about this.

[jonringer]

cc @NixOS/darwin-maintainers

[LnL7]

Yeah, this is probably something that should be tackled (along with reviving the llvm update) once Big Sur support is in.

[SuperSandro2000]

I just encountered a python module which requires SystemExtensions which is only available on 10.15+.

[SuperSandro2000]

I created #101940 to resolve this Issue. I did so far no real testing and would appreciate some help and advice.

[SuperSandro2000]

I also found https://github.com/phracker/MacOSX-SDKs. I am not sure at all if this is a trust worthy source but maybe for testing a good option.

[siraben]

10.13 is being EOL'd soon, as during the last decade Apple generally ends support for an OS (and thus its SDK) three years later. https://en.wikipedia.org/wiki/MacOS_version_history#Releases . Should we update to 10.14 SDK instead?

[SuperSandro2000]

I did not find a link (https://github.com/NixOS/nixpkgs/pull/101940/files#diff-c4d8bbc3261c329aad6d37bf66765868a01dcf4b838d8622d16959d8597ebed8R20) for 10.14. Maybe someone else has better luck than me.

[LnL7]

I'm not sure what sdk this is we're using right now but the CLT is available there which should also contain everything we need.

http://swcdn.apple.com/content/downloads/41/57/061-26573-A_JMOA8GZGDR/lj8yrtu8dgs40fw9k8f5fkoviwkp0og6vs/CLTools_SDK_macOS1014.pkg

[siraben]

Related:
#106679 (fails to compile because requires newer SDK)

[prusnak]

Maybe we should update to SDK 10.14, not 10.13, because #95199 mentions that Qt 5.14+ requires SDK 10.14

[r-burns]

I think based on apple's previous EOL schedules, they will probably be dropping support for 10.13 in the next few months now that big sur is out, so jumping to 10.14 could be timely

[siraben]

Agreed, going to 10.14 is better because 10.13 will be EOL'd soon.

[holymonson]

I'm building webkitgtk and find it requires 4 backport of macos system headers. (Related #106818 #107189)

    # FIXME: remove below patch after libproc.h update to 10.12 or above
    ./fix-WTF-headers.patch
    # FIXME: remove below patch after Libsystem-osx update to 10.14 or above
    ./fix-CommonCrypto-headers.patch
    # FIXME: remove below patch after Libsystem-osx update to 10.15 or above
    ./fix-qos-headers.patch
    # FIXME: remove below patch after Libsystem-osx update to 11.1 or above
    ./backport-MSG_NOSIGNAL-in-socket_h.patch

I'm surprised that we are stuck on an outdated SDK so long (FYI, homebrew will drop support on EOL versions immediately). Since Nix is so good at version management and overwriting, why don't we offer higher SDKs that some packages could depend on? (Of course, base packages should always depend on the lowest one). So here is several choices:

1. Update to SDK 10.14, and do nothing on higher SDK. For packages requiring higher SDKs, backport on their own.
2. Provide several versions of higher SDK that packages could explicitly demand. We may need a variable like NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM to allow low macOS to use high SDK.
3. Split the whole SDK into independent libraries (and keep a lowest SDK), so packages could demand their necessary ones.

I know maintainers are busy dealing with Apple Silicon, but this issue deserves more attention. Thanks.

[SuperSandro2000]

why don't we offer higher SDKs that some packages could depend on?

It is to much work to maintain multiple versions of the SDK. This would also mean we would need to maintain two versions of every tool listed here https://opensource.apple.com/release/macos-10136.html.

The update is simple blocked by lack of time. Someone just needs to do it which makes this entire discussion a bit pointless.

It is not as easy as just updating the library. See the PR which did the update to 10.12.

I simply do not have the time right now to try to do this and others probably, too.

[FRidh]

Mesa in staging-next requires 10.13+. #107783 (comment)

[siraben]

Is there a certain threshold until it becomes imperative to update to 10.13? I'd like to help efforts as well but there's a lot to do and it would be nice if we had a tracking project.

[SuperSandro2000]

should we only use it when necessary?

For now I would just keep doing that until takes overhand.

[mitchmindtree]

Is anyone successfully using the 10.13 SDK in their Nix darwin builds somehow?

Curious if there is some external repo hosting all known SDKs, even if they're not available in nixpkgs yet?

I think we'll likely start to see more issues around this now that GitHub have updated their macos-latest runner to 10.13 - as a result, some libraries that conditionally target newer APIs by checking the underlying OS version at build time are going to start failing with linker errors when they try to link to SDK functions that only exist in 10.13 as nixpkgs is only providing the 10.12 SDK.

We've run into this recently attempting to build the sysinfo crate depenency on the new macos-latest runner FuelLabs/fuel.nix#64 - it appears to attempt to use the _kCFURLVolumeAvailableCapacityForImportantUsageKey API when built on 10.13 which is only available on 10.13+. I was mistaken! See below.

Are there any active WIPs adding apple_sdk_13_0 to nixpkgs?

[reckenrode]

10.13 or 13.x? That announcement is for a macOS 13 runner.

#229210 is working to add the 13.3 SDK plus others. It is dependent on #234710 to bump the LLVM in the Darwin stdenv because clang 11 isn’t able build the 13.3 SDK. The LLVM update will be to 15 or 16 (depending on the amount of breakage).

[mitchmindtree]

Ahh I'm mistaken - it looks like we're still encountering the same issue with the macOS runner on macos-12, and that both macos-latest and macos-12 are still using macos 12.6.5 anyway!

It seems the source of non-determinism in our macos builds must be coming from elsewhere.

Apologies for the noise!

[reckenrode]

We've run into this recently attempting to build the sysinfo crate depenency on the new macos-latest runner FuelLabs/fuel.nix#64 - it appears to attempt to use the _kCFURLVolumeAvailableCapacityForImportantUsageKey API when built on 10.13 which is only available on 10.13+.

I wanted to address this separately. Depending on the 11.0 SDK should be sufficient. According to the Apple documentation, that API was added in 10.13 (which is not the same thing as macOS 13).

[reckenrode]

Apologies for the noise!

It was a good prompt to link some of the recent work on SDK- and stdenv-related stuff. There’s still work to be done after that on new SDK patterns to allow incremental “source-ification” of these SDKs, but it’ll allow more things to be built from source on a modern SDK (e.g., MoltenVK really should be built against latest, Blender requires 12.x, etc).

[reckenrode]

I am working on refactoring Darwin and how SDKs are used. The new pattern constructs a full SDK, which can be added as a package to buildInputs to change the SDK used in the stdenv. No more callPackage. No more overrideSDK. xcbuild will also automatically use the SDK set up in the stdenv. It is no longer hardcoded. The following SDKs will be supported: 10.12.2, 10.13.2, 10.14.6, 10.15.6, 11.3, 12.3, 13.3, 14.4. The default SDKs are not changing, but changing them should be easy.

I have all of the above SDKs building some packages via an adapter. I have MoltenVK and Wine building against the 14.4 SDK. I have some source release packages (libutil) building with the 14.4 SDK and an older deployment target, so they are usable on old platforms still. I have PyTorch building from source with MPS support (addressing #243868). Once I have the bootstrap done, I can test wezterm (addressing #239384). So far, adding the new SDK has Just Worked™.

The timeline for this will depend on how long it takes me to get it bootstrapping. The bootstrap changes are non-trivial, but it appears I can do it without needing an update to the bootstrap tools. Thankfully, they include xar and cpio on both platforms. I also need libtapi and jq, but the question is whether it is possible to build them somehow first. In the absolute worst case, I can use a special extra bootstrap mode that doesn’t do the cleanups and processing required for a proper SDK in nixpkgs. I’d like to get this into the next staging-next cycle, but that could be aggressive. It’s definitely coming for 24.11.

[emilazy]

Linking #338695 here for those subscribed to this issue.

[reckenrode]

https://discourse.nixos.org/t/on-the-future-of-darwin-sdks-or-how-you-can-stop-worrying-and-put-the-sdk-in-build-inputs/50574 is the Discourse discussion with the plan for updating the SDKs and my current status.

[aviallon]

Closed by #346043

[arianvp]

Amazing. Thanks so much