<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>
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.
<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
<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`