| 26 Feb 2026 |
 alexfmpe | ok so the same build with llvm 21 yields this as warning rather than error | 19:12:48 |
| alexfmpe | ../localedef/parser.y:232:18: warning: incompatible pointer types passing 'wchar_t[2]' (aka 'int[2]') to parameter of type 'char *' [-Wincompatible-pointer-types]
232 | copy_category(w);
| ^
| 19:12:55 |
| alexfmpe | maybe clang 22 got stricter with -Wincompatible-pointer-types ? | 19:13:19 |
| alexfmpe | curiously I ran into a similar "incompatible-error-types is now error" last year with nixpkgs-built ghc | 19:17:02 |
 Randy Eckenrode | They made it an error in Clang 22. | 19:17:05 |
| alexfmpe | so I'm surprised it wasn't already an error | 19:17:13 |
| alexfmpe | ah but I think that was gcc | 19:17:40 |
| alexfmpe | because I was doing linux->ucrt64 | 19:17:49 |
| alexfmpe | kay this fixes it
- env.NIX_CFLAGS_COMPILE = "-I${privateHeaders}/include";
+ env.NIX_CFLAGS_COMPILE = "-I${privateHeaders}/include -Wno-error-incompatible-pointer-types";
| 19:19:40 |
| Randy Eckenrode | https://releases.llvm.org/22.1.0/tools/clang/docs/ReleaseNotes.html#c-c-language-potentially-breaking-changes | 19:19:49 |
| alexfmpe | this seems harmless for <22 so it can just target master no? | 19:20:35 |
| Randy Eckenrode | It’s in the stdenv bootstrap, so it will cause mass rebuilds. | 19:22:13 |
| alexfmpe | oh right, what I really meant to ask was does-this-count-as-forward-compat | 19:23:10 |
| alexfmpe | no need to wait for any other llvm22 stuff to PR? | 19:23:28 |
| Randy Eckenrode | It should be harmless for LLVM 21. | 19:23:38 |
| alexfmpe | I'm surprised so far there's little fallout from incompatible-pointer-types becoming an error | 19:24:23 |
| Randy Eckenrode | Did GCC do it first? | 19:24:42 |
| alexfmpe | ah yeah could be from that | 19:25:43 |
| alexfmpe | something definitely got first blood last year | 19:26:01 |
| alexfmpe | e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13919 | 19:26:04 |
| alexfmpe | * e.g. https://gitlab.haskell.org/ghc/ghc/-/issues/26337 | 19:26:22 |
| alexfmpe | guess I'll let this run for another couple hours and see if there's anything else load-bearing going ape | 19:26:57 |
| alexfmpe | huh chromium doesn't eval on aarch64-darwin | 19:34:05 |
| alexfmpe | trying all the other suggestions
these 705 derivations will be built: | 19:34:16 |
 @logn:zirco.dev | guyyyyyys my nix disappeared again what am i supposed to do | 20:13:16 |
| @logn:zirco.dev | it's after an update, I remember this happens | 20:13:25 |
| @logn:zirco.dev | but forgot how to fix it | 20:13:28 |
 samasaur | macos reverted to the default shell init files in /etc, you should just need to add the block that Nix adds when it is installed:
# Nix
if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
. '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
fi
# End Nix
| 20:15:54 |
| samasaur | I don't remember if there's a "nice" way to do that with the upstream nix installer (which I suspect you used) and without nix-darwin | 20:16:22 |
| alexfmpe | * kay this fixes it
- env.NIX_CFLAGS_COMPILE = "-I${privateHeaders}/include";
+ env.NIX_CFLAGS_COMPILE = "-I${privateHeaders}/include -Wno-error=incompatible-pointer-types";
| 20:41:08 |
