Is this meant to fix builds of the dotnet_8/9 packages, or just a particular use of the SDK? I've been able to build all the SDK tests on darwin, including AOT, so I'm just wondering if there's a way we can get test coverage of the problem.

Also, the targets file fix looks like it might also apply to the binary SDKs. Should we perhaps be patching those here:

or maybe even in pkgs/build-support/dotnet/fetch-nupkg/overrides.nix, if it's not needed at restore time?

The nixfmt-check errors are for files not in this PR.

I've been able to build all the SDK tests on darwin, including AOT, so I'm just wondering if there's a way we can get test coverage of the problem.

I just tested this again on master, and dotnetCorePackages.dotnet_9.sdk.tests.aot works. I figured this would either fix the SDK build itself, or that test.

Should I be testing on the target branch of this PR?

Should I be testing on the target branch of this PR?

This is a follow up PR (hence draft) for the Darwin refactor in #346043. It also depends on #346947 to fix the Swift build after the refactor is merged. You probably want to test on the target branch with the Swift PR and this one applied.

Background

The Darwin refactor significantly changes how SDKs work in nixpkgs. Instead of having individual frameworks that you need to add, the stdenv has a default SDK (10.12 and 11.3 for x86_64-darwin and aarch64-darwin respectively). The old frameworks have been converted into stubs for evaluation compatibility purposes. The only time you will need to worry about the SDK is when you want to change the default, which you do by adding it as a package.

The Darwin SDK provides all frameworks together and propagates certain packages that it builds from source (like libiconv and libresolv). It is also set up to work with xcbuild and provides xcrun in the stdenv, so it is no longer necessary to override xcbuild to change the SDK version. In many cases, packages that try to find executables using xcrun should just work (e.g., xcrun --find clang will return the clang from the stdenv).

As a consequence of providing a full SDK, some changes are needed to packages. Swift framework overlays are located at $SDKROOT/usr/lib/swift (per a normal SDK). Clang would normally be able to find them there, but clang in nixpkgs is patched to ignore $SDKROOT/usr paths by default. The Swift wrapper will take care of that, but the .NET build invokes clang not Swift, so it needs the path added.

Other Items of Interest

This is one of the few packages that uses darwin.ICU. It has been upgraded to 74221, which is the version shipped in macOS 15 and corresponds roughly to ICU 74.2. It has been refactored to build like the standard, top-level icu package (with all the same dev outputs and dylibs) with a compatibility libicucore.A.dylib.

Going forward, the Darwin source releases will be updated regularly as Apple releases updates. darwin.ICU may be made the default, top-level icu for Darwin in 25.05 (like darwin.libiconv is currently).

Also, the targets file fix looks like it might also apply to the binary SDKs.

I’m not sure whether it’s needed, but it probably doesn’t hurt to apply it. Is there a good candidate package I can test?

dotnetCorePackages.{dotnet_8.sdk,sdk_9_0}.tests.aot would test AOT compilation in both the binary and source SDKs.

I'm trying it on your branch, but I'm getting:

error: builder for '/nix/store/lfq3wbci4sxx7k9ximqnvs7kznms57ng-libiconv-107.drv' failed with exit code 137;
       last 4 log lines:
       > structuredAttrs is enabled
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/2xcdfxid23dplkmg7mrb9li0p6j5lcj4-source
       > source root is source
       For full logs, run 'nix log /nix/store/lfq3wbci4sxx7k9ximqnvs7kznms57ng-libiconv-107.drv'.

That’s not good. The linker is crashing building libiconv. Does it happen every time? What architecture?

This is the community darwin builder, aarch64-darwin. However, I don't think the linker is crashing. If I run it in a shell, the failing command seems to be:

$ openssl sha256 -binary source/libiconv.xcodeproj/project.pbxproj
Killed: 9

This seems to be from pkgs/os-specific/darwin/xcode-project-check-hook/setup-hook.sh: hash=$(openssl "$hashType" -binary "$sourceRoot/$xcodeProject/project.pbxproj" | base64).

Also:

[nix-shell:~/nixpkgs]$ which openssl
/nix/store/7l1sw0303mnia33xk8b6ripmqzpigb16-openssl-3.3.2-bin/bin/openssl

[nix-shell:~/nixpkgs]$ openssl
Killed: 9

Oh, yeah. That’s a known problem until the bootstrap tools are updated. Someone with root access needs to sudo codesign -s - -f /nix/store/7l1sw0303mnia33xk8b6ripmqzpigb16-openssl-3.3.2-bin/bin/*.

I don't have root, unfortunately. Is there a way I can test with the updated bootstrap tools?

dotnetCorePackages.{dotnet_8.sdk,sdk_9_0}.tests.aot would test AOT compilation in both the binary and source SDKs.

Thanks, but dotnetCorePackages.dotnet_8.sdk.tests doesn’t appear to have AOT tests. I’m on staging as of last night.

nix-repl> dotnetCorePackages.dotnet_8.sdk.tests.
dotnetCorePackages.dotnet_8.sdk.tests.console
dotnetCorePackages.dotnet_8.sdk.tests.publish
dotnetCorePackages.dotnet_8.sdk.tests.self-contained
dotnetCorePackages.dotnet_8.sdk.tests.single-file
dotnetCorePackages.dotnet_8.sdk.tests.version
dotnetCorePackages.dotnet_8.sdk.tests.web

Should I do dotnet_9 and sdk_9_0?

Should I do dotnet_9 and sdk_9_0?

Yes, sorry, should be {dotnet_9.sdk,sdk_9_0}. The binary version of 8 should also support AOT, so you could do {dotnet_9.sdk,sdk_9_0,sdk_8_0}.

Update: I just saw your comment. I’ll test AOT on the binary 8.0 SDK and do the console test on the source-built 8.0 one.

This is what I’m building to test (with Microsoft.NETCore.Native.Unix.targets also patched in patch-nupkgs.nix). I’m currently building Qt WebEngine, so it’s queued to build after that to keep the load reasonable.

$ nix-build --log-format multiline . -A dotnetCorePackages.dotnet_8.sdk.tests.console -A dotnetCorePackages.sdk_8_0.tests.aot -A dotnetCorePackages.dotnet_9.sdk.tests.aot -A dotnetCorePackages.sdk_9_0.tests.aot --keep-going

I adapted the replacement to patch-nupkgs.nix.

LGTM. Thanks!