| 6 Sep 2025 |
 maralorn | In reply to @sternenseemann:systemli.org
maralorn: Cabal-syntax is reinstallable, ghc not; so that's probably the reason Good point | 11:11:59 |
 sterni (he/him) | emily: would you look at that https://gitlab.haskell.org/ghc/ghc/-/commit/50842f83f467ff54dd22470559a7af79d2025c03 | 17:30:44 |
| sterni (he/him) | though I think it fails at configure time (?) | 17:31:48 |
 emily | 😅 | 17:31:54 |
| emily | good timing I suppose | 17:32:00 |
| emily | I think it was already a warning before | 17:32:33 |
| emily | I guess they made it an error and then reverted that? | 17:32:43 |
| sterni (he/him) | yeah sounds like it, tbh I linked this before I read the diff | 17:37:14 |
| sterni (he/him) | configure would still fail looks like | 17:38:43 |
| sterni (he/him) | but I guess the wording is significant… | 17:38:55 |
| emily | insofar as LLVM support on old GHCs is cared about it still makes sense to backport even the trivial bumps because it shuts up the warning on every single .hs | 18:10:56 |
| emily | but yeah, when I was looking over all the issues and patches and bumps it seemed like the compatibility issues were all "obvious hard error from CLI change" type things (and even some of those only discovered/fixed after the fact) | 18:12:20 |
| emily | there's things like the LoongArch64 -mcmodel stuff that I linked in the file, but those aren't really related to the version | 18:12:48 |
| emily | like there are "non-obvious bugs/infelicities in the LLVM backend" and there are "obvious compat issues with how they invoke it that produce hard errors when bumping the version", but I couldn't really find anything in the intersection of those | 18:14:02 |
| emily | and several of the bump changes make it clear that the QA process is just "make sure it bootstraps" anyway | 18:14:28 |
| emily | er not intersection exactly. you know what i mean :) | 18:15:20 |
| sterni (he/him) | LLVM backend could be totally unusable already now and we wouldn't really know unfortunately. | 18:22:29 |
| sterni (he/him) | technically, this fix would help LLVM 19 compat insofar as it helps LLVM >= 3.4.0 compat :D https://gitlab.haskell.org/ghc/ghc/-/issues/25019 | 18:26:12 |
| emily | well, it works enough on 9.4 with my patches to build GHC itself at least… | 18:29:30 |
| emily | but yeah I don't get the impression there is much care for it | 18:29:53 |
| emily | even the LoongArch64 person making an mcmodel fix was like "this isn't a good fix because we should just have NCG" | 18:30:03 |
| sterni (he/him) | true, but we don't really exercise it with later versions of GHC I think | 18:30:04 |
| emily | I did my best, though, in terms of backporting everything LLVM-version-relevant | 18:30:30 |
| emily | pretty sure I was more thorough than upstream is when bumping from what i saw | 18:30:52 |
| sterni (he/him) | yes, I did not find anything you missed; except for a fix for llvm-ar >= 17, but that's unrelated to the llvmPackages we take as an input | 18:35:04 |
| sterni (he/him) | I think worrying about hostPlatform.useLLVM is for some other time | 18:35:24 |
| emily | hm would that not be picked up from the wrapping we do? | 18:37:59 |
| emily | ah I guess it would still just use the regular ar by default? | 18:38:00 |
| emily | not sure what ar we use on Darwin tbh | 18:38:00 |
| sterni (he/him) | I think GHC just uses AR, but that's only llvm-ar if useLLVM in nixpkgs (or does darwin use it?). As such it's also controlled by the global default LLVM version, so orthogonal to what we're doing | 19:21:28 |
