<abathur> but then someone posted about how the command-flag we need to bootstrap the mountpoint for a nix-store volume without a reboot stopped working
<abathur> and I was nerd-sniped, needed to know if there was going to be a mitigation or if I should just start sad-prepping to move everything to linux
<abathur> luckily they'd just renamed the flag I guess
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 244 seconds]
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 244 seconds]
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 244 seconds]
<thefloweringash> As for building things (ie, linking) on Big Sur, I’m still working solidly on it. I started refactoring stdenv a bunch to but it’s remarkably delicate.
<thefloweringash> As is, IIUC, clang and bintools are always set to bootstrap for the entire stdenv: https://github.com/NixOS/nixpkgs/blob/811709ff942a9cba4b6b7765c712d7e1cadb80e1/pkgs/stdenv/darwin/default.nix#L78-L115
<thefloweringash> So swapping out bintools for a rebuilt version with libtapi support isn’t possible.
<thefloweringash> So either it’s update bootstrap tools (which also needs a couple of fixes for refactored clang/compiler-rt), or try to refactor stdenv to be more bootstrappy.
<thefloweringash> and if you just want to see or test what I'm working on, this branch should work on big sur: https://github.com/thefloweringash/nixpkgs/tree/big-sur-integration
nikivi has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
nikivi has joined #nix-darwin
<LnL-> abathur: so that means our current binaries still work but you can't build anything new?
<thefloweringash> not the target, but this seems to be the case. the dyld cache can resolve the proxy libraries dependencies
<LnL-> right so no changes in the symbols/libraries
<LnL-> I don't really get your question about binutils tho
<LnL-> if that needs tapi then doesn't it need to be enabled all the way, starting in the bootstrap tarball
LnL- is now known as LnL
<thefloweringash> that's the conclusion I'm coming to
hedgie_ has joined #nix-darwin
<thefloweringash> I was thinking that there should be a single middle ground that produced a stdenv that would work on big sur, but not be bootstrappable on big sur
<LnL> ah, so your updated one is only clang?
<thefloweringash> s/single//
<thefloweringash> something like stage0: proxy libsystem, stage1: binutils+cctools-port+libtapi, stage2: tbd-libsystem, stage3: libc++, libc++abi, stage4: llvm, clang, etc
<thefloweringash> then when the dust settles, we could update bootstrap tools to get rid of the proxy library entirely
<thefloweringash> but i've spent a bit of time on this, and keep running into little things that break it.
<LnL> right, can't we build a fully compatible bootstrap tools in one go?
hedgie has quit [Ping timeout: 244 seconds]
<thefloweringash> that'd be another option I haven't tried yet, I'm thinking that would require a tbd-libsystem based stdenv that's only used to build bootstrap tools
<thefloweringash> it's not immediately obvious to me how to go about defining that
<LnL> so I think the first goal is a working stdenv that can build a new bootstrap tools
<LnL> with that working we could fire off a hydra build (without bootstrap tools for big sur)
<LnL> that gives us a view on the impact of the stdenv changes as well as a new official bootstrap tools which should be compatible
<thefloweringash> the goal new bootstrap tools here: is this the version that can bootstrap on big sur (libtapi, no proxy libsystem, maybe tbd libsystem), or the easier target of being able to produce a stdenv for big sur (libtapi, proxy libsystem, no tbd files)
<LnL> yeah exactly
<thefloweringash> that was meant to be two options!
<LnL> right ok so the later needs all of the former except for the bootstrap build itself
<LnL> and maybe some bootstrapping shenanigans, but you already got tapi up in the right place I thought
<thefloweringash> the easy and not-clever way of achieving the latter is to update bootstrap tools once staging hits master
<LnL> but I think other than maybe adding tapi there I think the build itself should mostly work when binutils, etc. have support
<LnL> I don't think we necessarily need to go through staging
<thefloweringash> ah, so bootstrap tools could have used `let cctools_ = darwin.cctools.override { enableTapiSupport = true; }`, then when it came time to update we'd also merge the corresponding change in stdenv bootstrap
<LnL> a wip build is easier to compare for regressions and that also gives an official build if stuff isn't rebased after
<LnL> yeah we could have done that, but I have the feeling that shortcut isn't really needed at this point anymore
<thefloweringash> yeah, the PR for tapi is on its way through staging now, so when it lands we'll be in the same place
<thefloweringash> concretely, the next step is to wait for staging to merge, and prepare a branch that includes new bootstrap tools and the tbd-libsystem?
<LnL> oh right, libsystem doesn't matter anymore because it's just a file
<LnL> that's pretty nice actually, then we can update that without changing the bootstrap tarball
<LnL> I think so in that case, how did you build your local thing?
<thefloweringash> in theory, for testing it was definitely easier to ship a set of .tbd files, but I don't see why we can't source those from in-tree (or wherever these land up)
<thefloweringash> local thing? the bootstrap on big sur branch?
<LnL> the bootstrap tools you used there
<thefloweringash> two rounds of bootstrap tools updates on a catalina, once to add tbd support, once again to drop the proxy library requirement
<LnL> but using the standard build?
<thefloweringash> yeah, just `nix-build .../make-bootstrap-tools.nix -A dist`
<thefloweringash> the commit history hopefully shows the broad strokes, even if it's a little messy: https://github.com/thefloweringash/nixpkgs/commits/big-sur-integration
<LnL> great, I think you're pretty much there then
<thefloweringash> so some lingering questions: where should the .tbd files be hosted, and are there any legal concerns about their contents?
eraserhd has quit [Quit: WeeChat 2.9]
<LnL> don't thing so, but I would put them in a separate repo
<LnL> especially if we include all the frameworks
nikivi has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
nikivi has joined #nix-darwin
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 244 seconds]
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 240 seconds]
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 240 seconds]
nikivi has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
nikivi has joined #nix-darwin
nikivi has quit [Client Quit]
nikivi has joined #nix-darwin
nikivi has quit [Client Quit]
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 244 seconds]
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 244 seconds]
eraserhd has joined #nix-darwin
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 244 seconds]
nikivi has joined #nix-darwin
philr has quit [Ping timeout: 240 seconds]
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 244 seconds]
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 244 seconds]
hedgie has joined #nix-darwin
hedgie_ has quit [Ping timeout: 244 seconds]
__monty__ has joined #nix-darwin
LnL has quit [Quit: exit 1]
hedgie_ has joined #nix-darwin
hedgie has quit [Ping timeout: 240 seconds]
LnL has joined #nix-darwin
nikivi has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
nikivi has joined #nix-darwin
__monty__ has quit [Quit: leaving]
philr has joined #nix-darwin