The Darwin SDKs have been updated

Thank a lot, Randy.
I just tried again no joy. However I did notice that the build failure message is much faster than before. Usually it would take me almost an hour to get the error msgs now it’s only 20-30 minutes…

My flake.nix is very standard comes right out the installation

nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";

and the env.system package using pkgs.wezterm

I don’t want to clutter this thread and maybe wait another day or two before trying again.

The Nixpkgs manual has a section on platform notes. They’ve been updated already but are currently getting further polishing in doc: revise Darwin SDK documentation by reckenrode · Pull Request #353439 · NixOS/nixpkgs · GitHub.

4 Likes

Please forgive my ignorance, but how do we go about joining this team?

Maybe it’s just a matter of similar action to this? maintainers: request to join postgres team by samrose · Pull Request #353673 · NixOS/nixpkgs · GitHub

From what I understand, unstable is currently blocked on a failure to build transmission_4-gtk. I have a patch for that, which should unblock the channel.

1 Like

I appreciate the interest!

We have two main ways for people to sign up to participate in Darwin maintenance. The first is the GitHub @NixOS/darwin-maintainers team, which you can ask to join by leaving a comment on this issue. It’s an informal collection of Nixpkgs maintainers who are interested in helping package and maintain software for Darwin, and acts as the front‐line contact for Darwin problems when people have issues building or testing their work on Darwin; the ping volume is relatively high but the solutions are usually relatively simple if you have experience with packaging software for Darwin, and it’s a great way to get involved.

The second is the Darwin team, assigned to lib.teams.darwin and @NixOS/darwin-core, which is assigned as the maintainer/codeowner of the kinds of critical infrastructure that Randy’s work here touched, like the Darwin standard environment, macOS SDK packages, and Apple source releases. I’d be more than happy to have more people involved; it’d be good to see some contributions to these areas first (whether in terms of sending PRs, doing code review, or investigating issues), but after that it’s just a matter of sending a PR to the teams list and getting added to the GitHub team. I linked examples of the kind of PRs we work on in the PR I linked to that properly established the team, but here are some more recent examples if it helps you judge whether you’re interested:

We tend to coordinate and discuss things in the Nix on macOS Matrix room, so if anyone wants to help out with Darwin platform support, please do come say hi!

5 Likes

@domenkozar I think that it would be good to promote and reignite the fundraiser again. I have stopped contributing on a recurring basis because the work has slowed or stopped. If this is used for funding macOS work again, as it just happened here (thank you for it and thanks @reckenrode for accepting it) - I would gladly get back to recurring donations, and I don’t think I am alone like that.

4 Likes

Hey all Darwin users. I encountered a build error on Darwin for a package I maintain, and I need small help with a review for a package that requires ScreenCaptureKit.h. I’m just not sure which sdk version to choose… Details here:

I usually search for the missing API at Apple’s developer site to see when it became available. In this case, ScreenCaptureKit appears to be a macOS 12.3 API.

2 Likes

I’m trying to make use of this, but running into a (probably unique to me?) problem where a CMake project can’t find -lpthread when using pkgs.pkgsStatic on darwin. I have no idea how to pass it in to buildInputs. Passing in pkgs.pkgsStatic.darwin.libpthread isn’t working, pkgs.pkgsStatic.darwin.apple-sdk_15. How do I reference libpthread with these changes?

darwin.libpthread is a stub package for compatibility with the old pattern. The required headers and text-based stubs for libpthread should be present in the SDK.

Is this a package in nixpkgs that’s failing to build? Do you have a failing example you can share? CMake required some changes to make it work on Darwin. I’m wondering if they’re not being applied in the static case (or if there are others being applied that need changes for Darwin).

Sadly it’s a proprietary package for work so I can’t share much. For some reason CMake’s inferring that it needs a -lpthread flag for its call to clang, and then it can’t find libpthread anywhere. I have pkgs.pkgsStatic.apple-sdk_15 as a buildInput for the derivation but I don’t know where to go from there to let CMake know where to find libpthread (symlinked to libSystem I believe?).

On an unrelated note, I noticed that darwin.Csu is marked as broken on arm, but it seems to compile fine for me - do you know why it has badPlatforms = [ {cpu = { family = "arm"; }; } ];? I also need it to be able to compile this binary statically.

(Apparently I need to change this body because I messed up my reply, hopefully this is enough noise to make discourse happy)

Is your build environment doing anything to SDKROOT or DEVELOPER_DIR? The new SDK pattern depends on those variables working. (Alternatively, if there’s a CMake-based package in nixpkgs that fails, that would also help troubleshooting.)

Csu is used when targeting 10.7 or older, which doesn’t apply on aarch64-darwin (where the minimum deployment target is 11.0). It may build, but does it work? There appear to be several places where there’s no arm64 assembly support.

Not as far as I can tell, I haven’t set it and none of the CMake files in the project mention any of them. I’ll see if I can figure out how to find a CMake based package!

This is probably related to the pthread issue - I had linker errors about linking against crt0.a (IIRC) and adding that in, with export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1 and --impure caused that problem to go away, but I still had issues with CMake deciding it needed to pass -lpthread.

What deployment target are you using? The default in nixpkgs should be new enough (10.12 and 11.0 for x86_64- and aarch64-darwin respectively, though it is changing to 11.3 for both in 25.05), but something may be overriding it.

Sorry for the radio silence, I ended up being able to figure out the static build issue I was having. We were (seemingly quire reaqsonably) adding -static to the linker on all non-Windows CMake builds. This is not the way to do things on macOS, and once that was removed CMake happily finds the appropriate .a libraries from pkgsStatic for darwin, and links executables which only have a dependency on the dynamic libSystem. With that all sorted, there’s no longer any need to find a way to link against libpthread to get static binaries.

(I’m trying to add as many keywords to this post so that search engines might suggest it in the future to help the next person who runs into the lack of info out there on doing this)

5 Likes