| 26 Jun 2025 |
 Alyssa Ross | SGTM | 20:57:02 |
 emily | that seems ideal yes :P | 20:57:04 |
 Grimmauld (any/all) | dangit | 20:57:11 |
| emily | sending the patch upstream will sanity check anyway | 20:57:15 |
| emily | ideally we wait for them to apply it and then switch | 20:57:24 |
| Grimmauld (any/all) | we also do have cmake 4, pkgconf+cmake sounds like a very fun cycle | 20:57:43 |
| Alyssa Ross | We could do CMake first given pkgconf will take time | 20:58:13 |
| emily | CMake and obliterating the bad CMake hook are immediately doable I think | 21:00:05 |
| emily | there's like one blocking issue with the CMake build itself and then it's just jobset tedium | 21:00:29 |
| emily | GCC 15 also probably doable | 21:01:01 |
| emily | LLVM 20 I know Randy is working on as part of his big branch | 21:01:20 |
| emily | btw pkgconf also breaks Meson tests on Darwin and I have no idea why | 21:02:33 |
| emily | we can probably just disable them but it scares me a little | 21:02:43 |
 Tristan Ross | Isn't that just an extension of my PR for bump to LLVM 20 but on the Darwin side of things? | 21:04:13 |
| emily | I think he did it independently beforehand? but I mostly mean I believe he has been fixing breakage along the way since he builds a lot of stuff | 21:05:03 |
| Tristan Ross | Gotcha | 21:05:17 |
| emily | and Darwin consumption of LLVM is changing too wrt libc++ so we probably don't want to run a cycle where we have a libc++ 20 on Darwin that we don't plan to ship | 21:05:48 |
| emily | (though hopefully I will be able to review that and other stuff this weekend anyway) | 21:06:06 |
| Tristan Ross | Great, yeah I believe I got the Linux side of the LLVM 20 bump covered already. | 21:09:05 |
| Tristan Ross | Currently getting back into the GCC NG stuff right now, trying to fix cross compilation. | 21:10:11 |
| 27 Jun 2025 |
|  R̴̨͕͇͍̞̮̐̅͆̌̀̉̐͋̈́̃̀͒́̎̅̚̚̚͠͝Ĕ̵̡̛͖͖̟̙̫̱͈̘̞̭͍͍͑̌̄͑̓̋̓̀̈̏̈́͊̇͊͆̉͂̏̀̃̚͘͝͝ͅͅD̶̡̢͔̱̖̮͙͉̘̺͓͍̩̮͈͍͗̃̀̏͌͘͜ͅŚ̸̬̭̯̬͙͇͓̬̩̳̤͚͓̤̩̺͉͖̉͛̓̿̎͊̿̆́̐͂̇͌̄̇̓͘ͅͅT̴̞̫̘̝͇͔̟̪̪̦͂̔̎̀̎ͅŎ̷̡̬̹̪͈̭̣͈̭̭͉̦̖̝̘̪͖͔̥̦̘̻̳Ṋ̶̛̫͈̳̘͚̜̔̋͆̅̈́͊̑͊̉̌̈́̾͑̈́̚ͅË̸̡̨̨̛͇̜̖͔͖̻̟̗̠̙͓̘̗̥͉͇̜͑͆͊͑͑̀̓͒͜͝͝ changed their display name from Redstone to R̴̨͕͇͍̞̮̐̅͆̌̀̉̐͋̈́̃̀͒́̎̅̚̚̚͠͝Ĕ̵̡̛͖͖̟̙̫̱͈̘̞̭͍͍͑̌̄͑̓̋̓̀̈̏̈́͊̇͊͆̉͂̏̀̃̚͘͝͝ͅͅD̶̡̢͔̱̖̮͙͉̘̺͓͍̩̮͈͍͗̃̀̏͌͘͜ͅŚ̸̬̭̯̬͙͇͓̬̩̳̤͚͓̤̩̺͉͖̉͛̓̿̎͊̿̆́̐͂̇͌̄̇̓͘ͅͅT̴̞̫̘̝͇͔̟̪̪̦͂̔̎̀̎ͅŎ̷̡̬̹̪͈̭̣͈̭̭͉̦̖̝̘̪͖͔̥̦̘̻̳Ṋ̶̛̫͈̳̘͚̜̔̋͆̅̈́͊̑͊̉̌̈́̾͑̈́̚ͅË̸̡̨̨̛͇̜̖͔͖̻̟̗̠̙͓̘̗̥͉͇̜͑͆͊͑͑̀̓͒͜͝͝. | 00:57:32 |
 Randy Eckenrode | I’ve been using it by default because Swift needs compiler-rt from LLVM 20, but I haven’t done any work to fix broken things other than what I’m doing now with Catch2 (because it’s not particularly broken on Darwin). | 01:56:30 |
| Randy Eckenrode | I created an issue to track Darwin stuff that mentions it, but I’m pretty sure it references Tristan Ross’s existing PR. | 01:57:12 |
| Randy Eckenrode | I’m trying to build my configs, so I can get the fixed Lix that uses a temporary location on the store volume instead of /tmp for builds. | 01:57:40 |
| Randy Eckenrode | I want to see how badly things break actually doing builds on case-sensitive APFS. | 01:57:50 |
| Randy Eckenrode | I’ll probably start splitting things up and cleaning it up again this weekend. I’m going to let Linux Swift be broken for a while because I need to get some of this stuff out for Darwin. | 01:58:48 |
| Tristan Ross | In reply to @reckenrode:matrix.org
I created an issue to track Darwin stuff that mentions it, but I’m pretty sure it references Tristan Ross’s existing PR. Oh yeah, I think I remember that issue | 01:58:50 |
| Randy Eckenrode | The only issue I know with using the system libc++ is the WASI stuff in Rust doesn’t like it. | 01:59:03 |
| Randy Eckenrode | But I have no idea how/why it works currently if it does. | 01:59:19 |
| Tristan Ross | Been working on GCC NG and cross has 1 issue left:
hello> In file included from /nix/store/51pba7q0zhhrzy7ia5yq273r49fa4hz2-glibc-riscv64-unknown-linux-gnu-2.40-66-dev/include/stdlib.h:1159,
hello> from lib/stdlib.h:51,
hello> from src/system.h:25,
hello> from src/hello.c:25:
hello> /nix/store/51pba7q0zhhrzy7ia5yq273r49fa4hz2-glibc-riscv64-unknown-linux-gnu-2.40-66-dev/include/bits/stdlib.h: In function 'wctomb':
hello> /nix/store/51pba7q0zhhrzy7ia5yq273r49fa4hz2-glibc-riscv64-unknown-linux-gnu-2.40-66-dev/include/bits/stdlib.h:98:3: error: #error "Assumed value of MB_LEN_MAX wrong"
hello> 98 | # error "Assumed value of MB_LEN_MAX wrong"
hello> | ^~~~~
| 02:11:23 |
