darwin bootstrap-tools bump LLVM to 11#121055
Conversation
6ebf3e0 to
423a47a
Compare
pkgs/os-specific/darwin/apple-source-releases/xnu/3789_70_16/default.nix
Outdated
Show resolved
Hide resolved
0b983d3 to
027d3fa
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
027d3fa to
152817e
Compare
152817e to
9c6795e
Compare
53c0636 to
4f1204a
Compare
a9046ab to
a95f566
Compare
|
Ok, so the latest force-push is the branch with all the changes bumping from LLVM 9 to 11 for both the Darwin bootstrap-tools and the stdenv. Commit 7db1708e adds an argument to For development I usually do the following: This relies on two commits since merging the Apple Silicon PR #105026, 2987d66 and 3820773. This may be relevant if we target staging. The latter wasn't present there last I checked. |
|
@toonn if this is ready for review, mark this PR as not draft (there are failing eval checks). |
|
@domenkozar, this PR is still a draft. There's probably package breakages we need to fix, working with @LnL7 to get a hydra jobset for this. I'm a little stumped by the ofborg-eval error tbh. I didn't touch |
|
That error will be fixed with #125184, hope to merge that tomorrow |
|
@domenkozar, ah, thanks. I had the weirdest case of déjá vu because of the "recommonmark." It's because I saw that PR earlier. |
I was having a hard time testing new bootstrapFiles because `make-bootstrap-tools.nix` imports `pkgspath` but does not pass anything but the current system. This is merely for convenience and I'm not entirely certain it's a sensible thing to do, maybe generating new bootstrapFiles while overriding the current bootstrapFiles isn't something you're supposed to do?
Credits to @LnL7, this is based on commit ae68f1c from PR NixOS#85151.
We need to include the library with the version suffix because `libclang-cpp.dylib` is just a symlink.
b5f8349 to
693f353
Compare
There was a problem hiding this comment.
Shouldn't be needed for the initial bootstrap build yet, removing the stdenv rebuild.
There was a problem hiding this comment.
You're right, forgot to remove it when adding it in make-bootstrap-tools.nix. >.<
There was a problem hiding this comment.
I'm still building the intermediate bootstrap-tools to verify that the preFixup hook actually works as expected btw.
There was a problem hiding this comment.
Overridden installPhase did the trick.
There was a problem hiding this comment.
Should I go ahead and mark this ready for review?
693f353 to
cad0245
Compare
`TargetConditionals.h` was missing several definitions, like `TARGET_OS_TV` that are part of SDK 10.12 at least. And one that doesn't seem to occur in any SDK afaict, `TARGET_OS_EMBEDDED_OTHER`. I added the definitions from SDK 10.12 verbatim and defined `TARGET_OS_EMBEDDED_OTHER` to be equal to `0`. This is a modified version of a patch to avoid a stdenv rebuild.
Changes to llvmPackages have caused the `libclang-cpp*.dylib` files to be included in the `clang-unwrapped.lib` output. So we no longer need to copy them from libclang.
cad0245 to
c7b433a
Compare
|
What happened to the global |
|
@sternenseemann, that's upcoming. We need this intermediate bootstrap-tools built first. |
|
@sternenseemann, continuing in #126411. |
Motivation for this change
To bump the Apple SDK we need an updated bootstrap-tools for the Darwin stdenv.
Current status
I have added two tags on my branch.
bs1points to the latest commit that can be built with the current bootstrap-tools, for everything after this you have to pass in this bootstrap-tools, and we need another bootstrap-tools to getdarwin.Csua dependency of stdenv to build, this would be taggedbs2.currentpoints to the commit I'm currently working on, something's depending on a libunwind path it shouldn't be when trying to make-bootstrap-tools. The commits dealing withdarwin.xnuanddarwin-stubsare specific to the Apple SDK bump. I have a messy build log of this, which may help (or hinder) understanding the changes.One big change in this branch is the bump from LLVM 7 to 11. This is because of this build failure. I didn't really see a way forward and another part of
darwin.CFwas problematic because of LLVM 7 anyway so @LnL7 figured I might as well try bumping stdenv (and bootstrap-tools) LLVM, this was based on previous work trying to bump it to 9 #85151. If the priority is to bump only the Apple SDK (and we find an alternative solution to that build failure) it might be less time consuming to delay the LLVM bump and continue on myapple_sdk-bumpbranch.cc @domenkozar