<supersandro2000> Can someone with more darwin experience than me help in https://github.com/NixOS/nixpkgs/pull/118461?
<{^_^}> #118461 (by aaschmid, 1 day ago, open): rmlint: darwin.support
__monty__ has joined #nix-darwin
philr has quit [Ping timeout: 260 seconds]
plumm has joined #nix-darwin
philr has joined #nix-darwin
andremedeiros has joined #nix-darwin
<stephank> Oh, annoying. nixpkgs-review uses nixFlakes, but I'm on a newer nix from master, so was confused. Apparently the nixFlakes it was using just hangs at the end of a --rebuild. :/
<stephank> But yeah, something about the PR is not deterministic
hedgie has quit []
qyliss has quit [Quit: bye]
qyliss has joined #nix-darwin
andremedeiros has quit [Read error: Connection reset by peer]
andremedeiros has joined #nix-darwin
hedgie has joined #nix-darwin
hedgie has quit []
philr has quit [Ping timeout: 240 seconds]
eraserhd2 has joined #nix-darwin
eraserhd has quit [Ping timeout: 260 seconds]
<__monty__> LnL: So I managed to build stage 3. Stage 4 fails to build swift-corefoundation, https://git.io/JmxTi
<__monty__> Is this error familiar to you at all? "expected function body after function declarator". But this is about a header so why would it be expecting a function body?
<__monty__> LnL: This seems to be triggering the workaround you added for the CFRuntime.c failure. But URL.subproj/CFURL.c isn't part of CFRuntime.c, right?
<__monty__> Hmm, this GCC looks maybe relevant. Maybe Clang 7 has a similar order dependency bug?
<LnL> hmm, doesn't look familiar
<LnL> CF comes from the swift corelibs since that's completely opensource
<LnL> so that's updated separately from the source releases or sdk, not sure what version we use exactly but I'd assume it's also 10.12 ish
<__monty__> LnL: And you think the swift-corelibs version is the issue or is it more likely to be the old clang?
<LnL> no idea, just pointing out that CF also needs an update
<LnL> FYI for an llvm update, I have a branch that got pretty far along for that
<LnL> but it's pretty stale at this point so will need a rebase, etc.
<{^_^}> #85151 (by LnL7, 51 weeks ago, open): [WIP] llvm 9 update
<__monty__> That reminds me. I'm currently doing this work on top of a month-old master commit. Because staging didn't build for me succesfully without changes. Is thissomething I'll have to tackle anyway at some point?
<LnL> it's also referenced in the apple silicon pr, which apparently updated to 11
<LnL> so there might also be stuff there that can be cherry-picked
<LnL> for staging, it will need to go there eventually but I wouldn't worry too much about keeping things up to date until the basics are working
<__monty__> Thanks, I'll look into it a bit more tonight and then look into updating LLVM as a next step tomorrow.
<__monty__> Re staging, I'm not worried about keeping up with master. More that maybe no one will fix the darwin stdenv situation on staging and dealing with it now might be easier than later when I have more commits on the branch.
<LnL> updating llvm would be good anyway, so if that's the issue here it's something that could be done first and integrated separately before the rest
<LnL> hopefully somebody else fixes things there before it becomes a big problem
<LnL> I used to be much more on top of that stuff
<__monty__> Do you know whether there's a relatively easy way to take a look at that problematic header file *after* macro expansion?
<__monty__> You can't be on top of everything when you're the bottom turtle ; )
<LnL> pretty sure there's a compiler flag to only run the preprocessor
<__monty__> Hmm, the error doesn't seem to occurr with clang 10. So I guess bumping LLVM is a good next step.
__monty__ has quit [Quit: leaving]
philr has joined #nix-darwin
supersandro2000 has quit [Disconnected by services]
supersandro2000 has joined #nix-darwin