| 12 Nov 2025 |
 samasaur | unsure how exactly that would happen though | 02:12:00 |
 jonhermansen | I really appreciate the help, thank you for taking a look. I'm glad it was just me that caused the problem 😆 | 02:15:46 |
| samasaur | no problem! glad you have a path forward! | 02:17:05 |
| jonhermansen | I'm taking your advice and will modify the darwin-store plist. I hope that the fact I have both /nix AND /nix/store is not a problem. wait4path may try to start nix-daemon too early... hmm | 02:17:58 |
| samasaur | it's wait4path /nix/store i think so hopefully it's OK | 02:18:19 |
|  Inayet changed their display name from inayet to Inayet. | 12:37:54 |
 niklaskorz | https://brew.sh/2025/11/12/homebrew-5.0.0/ | 19:36:41 |
| niklaskorz |
Homebrew prefers LLVM’s clang over gcc on macOS.
they didn't before? wow
| 19:36:54 |
 toonn | GCC on macOS has been an alias for Clang for years, no? | 21:47:29 |
| samasaur | from the Xcode toolchain, yes | 21:50:49 |
| samasaur | I guess that's referring to what happens when you have GCC and clang installed via homebrew and you install something that has to build from source? | 21:51:43 |
 Randy Eckenrode | https://github.com/Homebrew/brew/pull/20696 | 22:06:33 |
| Randy Eckenrode | Redacted or Malformed Event | 22:06:55 |
| Randy Eckenrode | * | 22:08:29 |
| niklaskorz | hm do I understand correctly that Apple clang was already prio 1 and that LLVM clang refers to the non-Xcode variant? | 22:16:11 |
| Randy Eckenrode | I think so. I don’t know how Homebrew handles specifying a compiler where Xcode doesn’t work. I can’t think of a situation where you would want to use upstream clang in lieu of Xcode if you actually have access to Xcode. | 22:17:36 |
| Randy Eckenrode | Maybe to use some other libc++, but Xcode clang can probably use it. | 22:17:54 |
| 13 Nov 2025 |
| samasaur | newer language features, right? | 00:10:26 |
| Randy Eckenrode | Apple’s Clang is not that far behind upstream. | 00:18:42 |
| samasaur | Yeah i think that is rarely a long-term issue but I remember it being necessary for btop in macports | 00:30:58 |
| Randy Eckenrode | btop needed libc++ features that weren’t available until LLVM 16. | 00:33:04 |
|  tao joined the room. | 05:27:51 |
| tao | Hi I've been trying to debug an llvm build failure on macOS with a maintainer of the llvm package over on the nixpkgs GitHub repo. They insist the build failure is a result of an older nixpkgs I must be running but my flake pins nixpkgs to unstable. They suggested I pop over here to see if the community can help me. Here's the GitHub issue where we talk through the causes: https://github.com/NixOS/nixpkgs/issues/460725#issuecomment-3523848126 and here's my repo: https://github.com/worldofgeese/fleek-nix-darwin | 05:31:12 |
| niklaskorz | What Tristan was asking for in that issue is that you reduce the config to a very small one that still fails | 09:39:56 |
| niklaskorz | It definitely is too much to expect from mantainers to build a 9gb darwin config to troubleshoot this issue | 09:40:19 |
| niklaskorz | (but I'm doing it right now nonetheless, which is why I know the size in the first place) | 09:40:51 |
| niklaskorz | * It definitely is too much to expect from maintainers to build a 9gb darwin config to troubleshoot this issue | 09:42:11 |
| niklaskorz | so yeah, it's your config, not an issue with nixpkgs | 09:48:09 |
| niklaskorz | why did you add these in the first place:
nix.enable = false;
nixpkgs.hostPlatform = {
config = "aarch64-apple-darwin";
system = "aarch64-darwin";
};
| 09:49:15 |
| niklaskorz | aarch64-apple-darwin is the wrong host triple | 09:49:23 |
