-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
Conversation
@thefloweringash Also pinging you since you did the initial work on the 11.0 SDK. |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
201416d
to
f10fb80
Compare
There was a problem hiding this 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?
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;
}; |
f10fb80
to
374c0ad
Compare
doc/stdenv/platform-notes.chapter.md
Outdated
{ 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 ]; | ||
# ... | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
9d5db4a
to
2d92e04
Compare
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) |
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. |
There was a problem hiding this 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.
Makes sense — sorry for the confusion! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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 I’m running |
After running
Running this on master, I also get a (different) error.
|
@reckenrode, does the new build command have a similar option to Those errors don't look good though, it seems that stdenv doesn't even build on master? |
I think
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. |
Following up: the hacky approach worked (changed |
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
Can you use sdk 11 in a nix-shell that only has https://discourse.nixos.org/t/remove-entries-from-nix-cflags-compile/20728 |
problem x86_64-darwin with rust |
apple_sdk_11_0: make available for use on x86_64-darwin
apple_sdk_11_0: make available for use on x86_64-darwin
apple_sdk_11_0: make available for use on x86_64-darwin
apple_sdk_11_0: make available for use on x86_64-darwin
apple_sdk_11_0: make available for use on x86_64-darwin
apple_sdk_11_0: make available for use on x86_64-darwin
apple_sdk_11_0: make available for use on x86_64-darwin
apple_sdk_11_0: make available for use on x86_64-darwin
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 requiresibtool
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.Sandbox: set to relaxed.
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes