Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apple_sdk_11_0: make available for use on x86_64-darwin #176661

Merged
merged 4 commits into from
Jul 8, 2022

Conversation

reckenrode
Copy link
Contributor

Description of changes

I discussed with @toonn on Matrix yesterday and this morning about the possibility of using the aarch64-darwin SDK on x86_64-darwin as an interim solution for software that needs a newer SDK. This was prompted by my wanting to build MoltenVK without needing Xcode.

I opened the PR against master because the changes required were quite small, and there are no rebuilds. The basic functionality tested was MoltenVK built with the SDK from nixpkgs (no Xcode).

See below for a screenshot of a functional demo app built almost entirely with nixpkgs (vkcube.app in vulkan-tools unfortunately requires ibtool from Xcode, but the actual code is compiled against the 10.12 SDK in nixpkg and linked against a MoltenVK built with the 11.0 SDK). A PR for MoltenVK will be forthcoming once this lands.

Screen Shot 2022-06-06 at 9 33 22 AM

Sandbox: set to relaxed.

Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 22.11 Release Notes (or backporting 22.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

@ofborg ofborg bot added the 6.topic: darwin Running or building packages on Darwin label Jun 7, 2022
@github-actions github-actions bot added the 8.has: documentation This PR adds or changes documentation label Jun 7, 2022
@reckenrode
Copy link
Contributor Author

@thefloweringash Also pinging you since you did the initial work on the 11.0 SDK.

@ofborg ofborg bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux labels Jun 7, 2022
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/902

@reckenrode

This comment was marked as duplicate.

@reckenrode

This comment was marked as duplicate.

@reckenrode reckenrode force-pushed the apple-sdk-11-x86_64 branch from 201416d to f10fb80 Compare June 7, 2022 05:44
Copy link
Contributor

@toonn toonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Only part I wonder about is why libobjc and Libsystem were gotten from the source releases before, I think that's the biggest change?

doc/stdenv/platform-notes.chapter.md Outdated Show resolved Hide resolved
@reckenrode
Copy link
Contributor Author

reckenrode commented Jun 7, 2022

LGTM

Only part I wonder about is why libobjc and Libsystem were gotten from the source releases before, I think that's the biggest change?

It’s conditional based on the platform. On aarch64-darwin, they come from the SDK. What this change does is always get them from the 11.0 SDK regardless (while keeping the defaults for each platform as-is).

# Pick the source of libraries: either Apple's open source releases, or the
# SDK.
useAppleSDKLibs = stdenv.hostPlatform.isAarch64;

selectAttrs = attrs: names:
  lib.listToAttrs (lib.concatMap (n: if attrs ? "${n}" then [(lib.nameValuePair n attrs."${n}")] else []) names);

chooseLibs = (
  # There are differences in which libraries are exported. Avoid evaluation
  # errors when a package is not provided.
  selectAttrs (
    if useAppleSDKLibs
      then apple_sdk
      else appleSourcePackages
  ) ["Libsystem" "LibsystemCross" "libcharset" "libunwind" "objc4" "configd" "IOKit"]
) // {
  inherit (
    if useAppleSDKLibs
      then apple_sdk.frameworks
      else appleSourcePackages
  ) Security;
};

@reckenrode reckenrode force-pushed the apple-sdk-11-x86_64 branch from f10fb80 to 374c0ad Compare June 7, 2022 11:39
Comment on lines 69 to 92
{ stdenv, overrideCC, xcbuild, AppKit, Foundation, Libsystem }:
let
clang_11_0 = stdenv.cc.override {
bintools = stdenv.cc.bintools.override { libc = Libsystem; };
libc = Libsystem;
};
stdenv_11_0 =
if stdenv.isx86_64 then
(overrideCC stdenv clang_11_0).override
{
targetPlatform = stdenv.targetPlatform // {
darwinMinVersion = "10.12";
darwinSdkVersion = "11.0";
};
}
else
stdenv;
xcbuild_11_0 = xcbuild.override { stdenv = stdenv_11_0; };
in
stdenv_11_0.mkDerivation {
buildInputs = [ AppKit Foundation ];
nativeBuildInputs = [ xcbuild_11_0 ];
# ...
}
Copy link
Member

@SuperSandro2000 SuperSandro2000 Jun 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to use this in nixpkgs I would suggest the following points.

  • be very careful. I think mixing SDKs could easily backfire and we need to carefully test this to make sure we don't break everything.
  • Can we add this to top level to make sure all packages use the same overrides? It would also make updating easier in case we discover bugs and need to change things later. This would mean we move this to top-level or darwin packages and remove the nix code here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussing it with @toonn on Matrix, I pushed an update that adds a stdenv attribute to the 11.0 SDK attribute.

@reckenrode reckenrode force-pushed the apple-sdk-11-x86_64 branch 3 times, most recently from 9d5db4a to 2d92e04 Compare June 7, 2022 20:13
@reckenrode reckenrode mentioned this pull request Jun 8, 2022
13 tasks
@willcohen
Copy link
Contributor

willcohen commented Jun 9, 2022

Just thinking about EOL dates, planning for this seems like a very reasonable stopgap between now and the next stable release. Since 10.15 is going to be EOL this fall, macOS 11 will be the oldest supported release at that time. I know that the tentative plan for #101229 is to try to get SDKs bumped by the fall nixos release, and if it's feasibly to get that up to macOS 11 by then, this workaround may have a max shelf life of something like 6 months and will be a chance to get all the stuff that's been lagging on darwin up to speed in advance of that bump (getting Qt 5.15 and 6 stuff settled, anything using go, etc)

@toonn
Copy link
Contributor

toonn commented Jun 9, 2022

We're not bumping that far. And I'm not entirely sure we even should keep up with Apple's support schedule. That leaves a lot of hardware out there without access to Nixpkgs and no tangible advantage for users on more recent systems.

The current idea is to keep the default SDK recent-ish (emphasis on the ish) and provide ways to build with newer SDKs only for packages that really need it.

Copy link
Contributor

@toonn toonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the most elegant way to expose this so it looks good to me.

@willcohen
Copy link
Contributor

Makes sense — sorry for the confusion!

Copy link
Member

@SuperSandro2000 SuperSandro2000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@toonn
Copy link
Contributor

toonn commented Jun 10, 2022

One sensible test that someone on aarch64-darwin should run is whether this has any effect on bootstrapping stdenv.

@reckenrode
Copy link
Contributor Author

One sensible test that someone on aarch64-darwin should run is whether this has any effect on bootstrapping stdenv.

What would be the best way to do that? When I try to build stdenv on aarch64-darwin after applying the change, nix still gets it from the cache.

I’m running nix store gc right now to clear things out, so I can disable substituters (--option substituters '' and have it rebuild as much as possible, but that’s going to take some time.

@bobby285271 bobby285271 added the 12.approvals: 2 This PR was reviewed and approved by two reputable people label Jun 10, 2022
@reckenrode
Copy link
Contributor Author

After running nix store gc, and trying to rebuild stdenv, I get an error.

$ nix build --rebuild .#stdenv --option substituters ''
error: derivation '/nix/store/f6d7lwrknzcwbsjds36sgfl6cqpp82qy-bootstrap-stage0-clang-wrapper-11.1.0.drv' requires non-existent output 'out' from input derivation '/nix/store/ns4bvhwbwjjwizgvm4h0yf5gz2p7x7mf-bash-5.1-p16.drv'

Running this on master, I also get a (different) error.

$ nix build --rebuild github:NixOS/nixpkgs#stdenv --option substituters ''
error: derivation '/nix/store/4xfgcw1ajb12hjgvqa2rxz2m88w6ab6x-clang-11-12-LLVMgold-path.patch.drv' requires non-existent output 'lib' from input derivation '/nix/store/rd66ahrsdnghs9yjibscm7rrxlw09afq-llvm-11.1.0.drv'

@toonn
Copy link
Contributor

toonn commented Jun 13, 2022

@reckenrode, does the new build command have a similar option to --check? That should normally rebuild rather than substitute even if it's already in the store.

Those errors don't look good though, it seems that stdenv doesn't even build on master?

@reckenrode
Copy link
Contributor Author

@reckenrode, does the new build command have a similar option to --check? That should normally rebuild rather than substitute even if it's already in the store.

I think --rebuild does the same thing. It rebuilds the derivation then compares it to the original. That succeeds; but, as far as I know, it’s not doing a bootstrap of stdenv (because none of the inputs changed).

Those errors don't look good though, it seems that stdenv doesn't even build on master?

That’s the way I read it, assuming disabling substituters is a supported scenario. Is there a better way of forcing a bootstrap of stdenv? I tried changing the name of bootstrapTools in its derivation this morning, and stdenv is rebuilding now, but that seems kind of hacky.

@reckenrode
Copy link
Contributor Author

Following up: the hacky approach worked (changed name = "bootstrap-tools"; to name = "bootstrap-tools-foo";. The aarch64-darwin stdenv rebuilt without issue.

@toonn toonn mentioned this pull request Jun 13, 2022
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-macos-monthly/12330/31

@SuperSandro2000
Copy link
Member

Can you use sdk 11 in a nix-shell that only has stdenv.mkDerivation?

https://discourse.nixos.org/t/remove-entries-from-nix-cflags-compile/20728

@PlumpMath
Copy link

ipetkov/crane#325 (comment)

problem x86_64-darwin with rust

rkaippully pushed a commit to awakesecurity/nixpkgs that referenced this pull request Jul 3, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
jsoo1 pushed a commit to awakesecurity/nixpkgs that referenced this pull request Jul 3, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
jsoo1 pushed a commit to awakesecurity/nixpkgs that referenced this pull request Jul 14, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
jsoo1 pushed a commit to awakesecurity/nixpkgs that referenced this pull request Jul 15, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
jsoo1 pushed a commit to awakesecurity/nixpkgs that referenced this pull request Jul 21, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
jsoo1 pushed a commit to awakesecurity/nixpkgs that referenced this pull request Aug 7, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
jsoo1 pushed a commit to awakesecurity/nixpkgs that referenced this pull request Sep 7, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
awake-bot pushed a commit to awakesecurity/nixpkgs that referenced this pull request Oct 20, 2023
apple_sdk_11_0: make available for use on x86_64-darwin
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: darwin Running or building packages on Darwin 8.has: documentation This PR adds or changes documentation 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 0 This PR does not cause any packages to rebuild on Linux
Projects
None yet
Development

Successfully merging this pull request may close these issues.