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

treewide: change various flags to allow x64 darwin to default to sdk 11.0 when ready #324155

Merged
merged 3 commits into from
Jul 9, 2024

Conversation

paparodeo
Copy link
Contributor

@paparodeo paparodeo commented Jul 2, 2024

Description of changes

continuation of #323679 which i closed and can not re-open.

with this change and plus a modification to lib/systems/default.nix x64 darwin will default to sdk 11.0.

the first commit modifies various conditionals to not assume that x86_64-darwin uses sdk 10.12 and instead checks the darwinSdkVersion. Additionally, darwin.xnu is modified so x64 darwin uses unwrapped clang when generating header files, as the headers require a 32 bit arch which is not allowed when using cc-wrapper as it sets -arch to x86_64. this commit is sufficient for building stdenv when darwinSdkVersion is set to "11.0" in lib/systems/default.nix.

the second commit fixes evaluation errors which assume that x64 darwin can access the apple_sdk.sdk attribute which is only available as part of the 10.12 sdk so rather than checking for x64 darwin, condition on darwinSdkVersion is older than "11.0".

with these two commits and the following diff x64 darwin will default to using sdk 11.0

enable sdk 11 on all platforms
--- a/lib/systems/default.nix
+++ b/lib/systems/default.nix
@@ -251,7 +251,7 @@ let
         else null;
       # The canonical name for this attribute is darwinSdkVersion, but some
       # platforms define the old name "sdkVer".
-      darwinSdkVersion = final.sdkVer or (if final.isAarch64 then "11.0" else "10.12");
+      darwinSdkVersion = final.sdkVer "11.0";
       darwinMinVersion = final.darwinSdkVersion;
       darwinMinVersionVariable =
         if final.isMacOS then "MACOSX_DEPLOYMENT_TARGET"

testing: using the patch to enable sdk 11, built inkscape and verified removing overrideSDK for a few sampled packages (vcpkg-tool, wasmedge) works.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • 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/)
  • 24.11 Release Notes (or backporting 23.11 and 24.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
  • Fits CONTRIBUTING.md.

cc: @emilazy @reckenrode

Add a 👍 reaction to pull requests you find important.

@github-actions github-actions bot added the 6.topic: stdenv Standard environment label Jul 2, 2024
@paparodeo paparodeo mentioned this pull request Jul 2, 2024
13 tasks
@paparodeo paparodeo changed the title treewide: change various flags to allow x64 darwin to default to sdk 11.0 treewide: change various flags to allow x64 darwin to default to sdk 11.0 when ready Jul 2, 2024
@ofborg ofborg bot added the 6.topic: darwin Running or building packages on Darwin label Jul 2, 2024
] ++ lib.optional (stdenv.isDarwin && !stdenv.isAarch64) (
] ++ lib.optional (stdenv.isDarwin && apple_sdk ? sdk) (
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this still necessary? libproc.h is included in the 10.12 SDK Libsystem and should be identical to this one.

Copy link
Contributor Author

@paparodeo paparodeo Jul 2, 2024

Choose a reason for hiding this comment

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

hmm, webkitgtk is marked as broken on darwin so not sure. i added a comment stating it might not be necessary and switched the check to sdk is < 11

# use unwrapped clang to generate headers because wrapper is not compatible with a 32 bit -arch.
# aarch64 should likely do this as well and remove the --replace MACHINE_ARCH above
MIGCC = if stdenv.isx86_64 && lib.versionAtLeast stdenv.hostPlatform.darwinSdkVersion "11"
then "${lib.getBin buildPackages.stdenv.cc.cc}/bin/clang"
Copy link
Contributor

Choose a reason for hiding this comment

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

mig needs to target the build platform because it’s run at build time to generate headers.

Suggested change
then "${lib.getBin buildPackages.stdenv.cc.cc}/bin/clang"
then "${lib.getBin pkgsBuildBuild.stdenv.cc.cc}/bin/clang"

Copy link
Contributor

Choose a reason for hiding this comment

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

I’d also add this can be done unconditionally. I do something similar in 37a87d0, but I think this way is probably cleaner. I can’t remember why I didn’t specify a full path to for MIGCC in that commit.

Copy link
Contributor Author

@paparodeo paparodeo Jul 2, 2024

Choose a reason for hiding this comment

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

i don't have aarch64 to test on. i suspect that making it unconditional means that MACHINE_ARCH doesn't need to get patched for aarch64 as well, and thus observing the comment saying that the header build needs to use 32 bit arch. it does change the layouts for the x64 darwin structures so i assume that the aarch64 ones have mismatched structure sizes as well.

i'd like this to be part of a followup given the lack of hardware and would require the PR to move staging. created #324440 -- will cause a merge conflict with this PR but should be easy enough to resolve.

@reckenrode
Copy link
Contributor

Also pinging @toonn.

update code to not assume that x64 darwin must use sdk 10.12. After this
change it's possible to build a sdk 11 stdenv on darwin x64
update code to not assume that x64 darwin uses sdk 10.12. These changes
want to reach into apple_sdk.sdk to grab a header file which is only
required for sdk 10.12.
@paparodeo paparodeo marked this pull request as ready for review July 3, 2024 00:30
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.

Most of it looks good to me, just a couple questions.

MIGCC = "cc";
# use unwrapped clang to generate headers because wrapper is not compatible with a 32 bit -arch.
# aarch64 should likely do this as well and remove the --replace MACHINE_ARCH above
MIGCC = if stdenv.isx86_64 && lib.versionAtLeast stdenv.hostPlatform.darwinSdkVersion "11"
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this shouldn't be conditional? Even the 10.12 script relies on the 32-bit arch compiler. Or does the wrapper only force a 64-bit architecture when using the 11 SDK?

@@ -150,7 +154,7 @@ appleDerivation' (if headersOnly then stdenvNoCC else stdenv) (
mv $out/Library/Frameworks/IOKit.framework $out/Library/PrivateFrameworks
'';

appleHeaders = builtins.readFile (./. + "/headers-${arch}.txt");
appleHeaders = builtins.readFile (./. + "/headers-${stdenv.hostPlatform.darwinSdkVersion}-${arch}.txt");
Copy link
Contributor

Choose a reason for hiding this comment

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

Will we ever want to split on more than the architecture? I'd say the goal is to unsplit these header checks eventually. If they're even still useful.

Copy link
Contributor

Choose a reason for hiding this comment

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

The way to do these in the future probably requires us to inventory the upstream SDKs and compare our headers to those in the SDK. Otherwise, using headers + stubs with more than a few SDKs is going to get painful quickly.

(Or I wouldn’t worry too much about the current situation because it’s going to need to change.)

Copy link
Member

@RossComputerGuy RossComputerGuy left a comment

Choose a reason for hiding this comment

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

LGTM, however I would like to get #325175 in before we merge any other LLVM changes to minimize rebasing and conflicts.

@toonn
Copy link
Contributor

toonn commented Jul 7, 2024

@RossComputerGuy, how close is that PR to being marked ready?

@RossComputerGuy
Copy link
Member

@toonn it's ready, trying to figure out CI failures. Should be ready tonight or within the next couple days.

@paparodeo
Copy link
Contributor Author

@toonn it's ready, trying to figure out CI failures. Should be ready tonight or within the next couple days.

so it is not ready.

@RossComputerGuy
Copy link
Member

so it is not ready.

The actual work is done, there's just CI roadblocks. I checked using nix-diff and rebuild count should be 0. It sounds like the CI issue it's having should be simpler enough and only affects Darwin.

@paparodeo
Copy link
Contributor Author

so it is not ready.

The actual work is done, there's just CI roadblocks. I checked using nix-diff and rebuild count should be 0. It sounds like the CI issue it's having should be simpler enough and only affects Darwin.

it only effects the builds which have a stdenv based on llvm. i am not sure how you think it is good etiquette to think that you should be able to open up a non-critical PR that creates merge conflicts with this one and then request that this not get merged so you don't have to resolve the merge conflicts with the files you deleted so I can deal with fixing them in this PR. And your PR doesn't even work yet. Fixing the merge conflicts is not really a big deal for me but your request is just rude.

@RossComputerGuy
Copy link
Member

Fixing the merge conflicts is not really a big deal for me but your request is just rude.

Sorry, it wasn't my intention to be rude. I'll merge this one first if nobody has anything left to address.

@paparodeo
Copy link
Contributor Author

Fixing the merge conflicts is not really a big deal for me but your request is just rude.

Sorry, it wasn't my intention to be rude. I'll merge this one first if nobody has anything left to address.

it doesn't really matter. i overreacted.

@RossComputerGuy RossComputerGuy merged commit 7a95a89 into NixOS:master Jul 9, 2024
28 checks passed
@paparodeo paparodeo deleted the x64-sdk11-no-rebuilds branch July 9, 2024 00:24
@wentasah
Copy link
Contributor

Hi,

in the nix-ros-overlay project, we're experiencing the following eval failure:

error: opening file '/nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/os-specific/darwin/apple-source-releases/xnu/headers-10.12-arm64.txt': No such file or directory

Can somebody here suggests what's wrong?

@paparodeo
Copy link
Contributor Author

Hi,

in the nix-ros-overlay project, we're experiencing the following eval failure:

error: opening file '/nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/os-specific/darwin/apple-source-releases/xnu/headers-10.12-arm64.txt': No such file or directory

Can somebody here suggests what's wrong?

arm64 doesnt support 10.12

@reckenrode
Copy link
Contributor

reckenrode commented Sep 19, 2024

Hi,

in the nix-ros-overlay project, we're experiencing the following eval failure:

error: opening file '/nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/os-specific/darwin/apple-source-releases/xnu/headers-10.12-arm64.txt': No such file or directory

Can somebody here suggests what's wrong?

Somehow stdenv.hostPlatform.darwinSdkVersion is being set to 10.12 on aarch64-darwin. The oldest version supported by aarch64-darwin is 11.0, which is the current default in nixpkgs.

appleHeaders = builtins.readFile (./. + "/headers-${stdenv.hostPlatform.darwinSdkVersion}-${arch}.txt");

@wentasah
Copy link
Contributor

wentasah commented Sep 19, 2024

Thanks for quick answers. I don't think we pin the SDK versions anywhere. Who and how can do that? Can you see something interesting from the trace? Posting just the end, which seems to contain some package names, not just generic nixpkgs stuff:

      … in the condition of the assert statement
         at /nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/build-support/cc-wrapper/default.nix:293:1:
          292| # Ensure bintools matches
          293| assert libc_bin == bintools.libc_bin;
             | ^
          294| assert libc_dev == bintools.libc_dev;

       … while calling the 'getAttr' builtin
         at <nix/derivation-internal.nix>:44:19:
           43|       value = commonAttrs // {
           44|         outPath = builtins.getAttr outputName strict;
             |                   ^
           45|         drvPath = strict.drvPath;

       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:34:12:
           33|
           34|   strict = derivationStrict drvAttrs;
             |            ^
           35|

       … while evaluating derivation 'Libsystem-1238.60.2'
         whose name attribute is located at /nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/stdenv/generic/make-derivation.nix:336:7

       … while evaluating attribute 'installPhase' of derivation 'Libsystem-1238.60.2'
         at /nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/os-specific/darwin/apple-source-releases/Libsystem/default.nix:36:3:
           35|
           36|   installPhase = ''
             |   ^
           37|     export NIX_ENFORCE_PURITY=

       … while calling the 'getAttr' builtin
         at <nix/derivation-internal.nix>:44:19:
           43|       value = commonAttrs // {
           44|         outPath = builtins.getAttr outputName strict;
             |                   ^
           45|         drvPath = strict.drvPath;

       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:34:12:
           33|
           34|   strict = derivationStrict drvAttrs;
             |            ^
           35|

       … while evaluating derivation 'xnu-3789.70.16'
         whose name attribute is located at /nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/stdenv/generic/make-derivation.nix:336:7

       … while evaluating attribute 'appleHeaders' of derivation 'xnu-3789.70.16'
         at /nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/os-specific/darwin/apple-source-releases/xnu/default.nix:152:3:
          151|
          152|   appleHeaders = builtins.readFile (./. + "/headers-${stdenv.hostPlatform.darwinSdkVersion}-${arch}.txt");
             |   ^
          153| } // lib.optionalAttrs headersOnly {

       … while calling the 'readFile' builtin
         at /nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/os-specific/darwin/apple-source-releases/xnu/default.nix:152:18:
          151|
          152|   appleHeaders = builtins.readFile (./. + "/headers-${stdenv.hostPlatform.darwinSdkVersion}-${arch}.txt");
             |                  ^
          153| } // lib.optionalAttrs headersOnly {

       error: opening file '/nix/store/l3amk5lsakpc93him5kry24kax23sn4h-source/pkgs/os-specific/darwin/apple-source-releases/xnu/headers-10.12-arm64.txt': No such file or directory

Full trace here.

@emilazy
Copy link
Member

emilazy commented Sep 19, 2024

Do you have a flake command that reliably reproduces the failure?

@wentasah
Copy link
Contributor

Yes: nix flake show github:lopsided98/nix-ros-overlay

@reckenrode
Copy link
Contributor

reckenrode commented Sep 19, 2024

I added tracing to your flake. It’s failing when it tries to evaluate armv7a-darwin.

Edit: This is a minimal reproducer:

$ nix eval --impure -E 'import (builtins.getFlake "github:NixOS/nixpkgs")  { system = "armv7a-darwin"; }'
error:
       … while evaluating a branch condition
         at /nix/store/7mfai28m4yqdnvhbyzd7jg57nzlwgc73-source/pkgs/stdenv/booter.nix:99:7:
           98|     thisStage =
           99|       if args.__raw or false
             |       ^
          100|       then args'

       … while evaluating 'args' to select '__raw' on it
         at /nix/store/7mfai28m4yqdnvhbyzd7jg57nzlwgc73-source/pkgs/stdenv/booter.nix:99:10:
           98|     thisStage =
           99|       if args.__raw or false
             |          ^
          100|       then args'

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: opening file '/nix/store/7mfai28m4yqdnvhbyzd7jg57nzlwgc73-source/pkgs/os-specific/darwin/apple-source-releases/xnu/headers-10.12-arm64.txt': No such file or directory

@wentasah
Copy link
Contributor

wentasah commented Sep 19, 2024

I guess, this is some niche platform, which we can disable. But probably it should not look for headers-*-arm64.txt, because it's 32bit platform.

@emilazy
Copy link
Member

emilazy commented Sep 19, 2024

armv7a-darwin is not a platform that has ever been supported or that really makes much sense beyond unsupported iPhones. You should probably use something more like Nixpkgs’ lib.systems.flakeExposed list.

@wentasah
Copy link
Contributor

Sounds like a good idea. Thanks to all for help.

@reckenrode
Copy link
Contributor

armv7a-darwin is included in lib.platforms.darwin for some reason. Maybe it worked in the past, but I can’t imagine it’s worked anytime recently. macOS has never supported 32-bit ARM (and Apple Silicon doesn’t implement it). iOS dropped support in iOS 11, which was released in 2017. Apple stopped accepting 32-bit submissions to the App Store in 2015.

wentasah added a commit to wentasah/nix-ros-overlay that referenced this pull request Sep 19, 2024
This gets rid of evaluation error for armv7a-darwin. It makes no sense
to support this platform in this overlay. According to the discussion
around around
NixOS/nixpkgs#324155 (comment),
it is better to support just the systems exposed by the nixpkgs flake.

Currently, these are:
- aarch64-darwin
- aarch64-linux
- armv6l-linux
- armv7l-linux
- i686-linux
- powerpc64le-linux
- riscv64-linux
- x86_64-darwin
- x86_64-freebsd
- 86_64-linux
lopsided98 pushed a commit to lopsided98/nix-ros-overlay that referenced this pull request Sep 19, 2024
This gets rid of evaluation error for armv7a-darwin. It makes no sense
to support this platform in this overlay. According to the discussion
around around
NixOS/nixpkgs#324155 (comment),
it is better to support just the systems exposed by the nixpkgs flake.

Currently, these are:
- aarch64-darwin
- aarch64-linux
- armv6l-linux
- armv7l-linux
- i686-linux
- powerpc64le-linux
- riscv64-linux
- x86_64-darwin
- x86_64-freebsd
- 86_64-linux
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants