| 1 Jun 2025 |
 sterni (he/him) | https://github.com/NixOS/nixpkgs/pull/413046 | 21:38:25 |
| sterni (he/him) | We need to resolve eval issues and can look into starting an eval tomorrow or in the next days, depending on how full the x86_64-linux queue is. | 21:49:12 |
|  NixOS Moderation Bot unbanned  @mightyiam:matrix.org. | 22:58:02 |
|  Sean Thawe joined the room. | 23:39:39 |
| 2 Jun 2025 |
 maralorn | Uh, why is pandoc pinned to 3.6 in stackage? | 11:04:25 |
| maralorn | We have a test error for pandoc on haskell-updates and it is fixed in 3.6.4. | 11:04:48 |
| maralorn | But apparently we are already backporting 2 patches for that one test … Lets make it 3. 😄 | 11:08:38 |
| sterni (he/him) | maybe newer pandoc no longer has a valid install plan with stackage lts | 11:58:31 |
| maralorn | Yes, that is likely it. | 12:07:32 |
 Teo (he/him) | Is there an easy way to configure the nixpkgs haskell infra to use lld as the linker? I'm currently working on adding support to haskell.nix for this and once I'm done with that I'd be keen to do the same for nixpkgs if it doesn't already exist | 12:08:39 |
| sterni (he/him) | probably just need to generalize the ld.gold mechanism, the question is of course why you'd do it. | 12:10:22 |
| sterni (he/him) | it's already kind of silly to use gold as a one off in haskellPackages | 12:11:10 |
| Teo (he/him) | Basically cause gold is being deprecated and also lld is better apparently | 12:11:23 |
| Teo (he/him) | Yeah I think it's kind of a conceptual mess how this all works | 12:11:33 |
| sterni (he/him) | surely the ld.bfd bug that was plaguing haskell has been fixed by now? | 12:11:55 |
| Teo (he/him) | I think the big issue with ld.bfd is that it is horribly slow | 12:12:16 |
| Teo (he/him) | At least given the huge object files that GHC outputs | 12:12:51 |
| sterni (he/him) | that's true | 12:13:06 |
| sterni (he/him) | but are we sure that a mix of lld and ld.bfd across nixpkgs can play nice with C++ libs? | 12:13:27 |
| Teo (he/him) | Yeah I'm not sure. Maybe the "correct" thing to do is just use lld consistently as the linker | 12:13:58 |
| Teo (he/him) | I guess then you want to use clang as well? Otherwise you don't get LTO(?) I don't know how C/C++ linker stuff works | 12:15:02 |
 emily | mixing linkers is fine | 12:18:43 |
| emily | but we probably won't want to use a different linker just for Haskell unless we need to | 12:18:56 |
| emily | OTOH both ld.gold and ld.bfd sort of suck for Linux to be on so maybe someone should make LLD happen system-wide :P | 12:19:23 |
| emily | (then again, I'd say the same about GCC vs. LLVM) | 12:19:35 |
| Teo (he/him) | The other thing is GHC supports using a different linker to what it was built with, but I'm not sure if it's worthwhile making use of that. You'd have to split it into a bindist derivation and an installed GHC derivation. It would save building GHC n times though | 12:21:31 |
| sterni (he/him) | emily: it's probably better to use lld over ld.gold longterm, but we'd have to check first how bad ld.bfd is nowadays | 12:43:43 |
| sterni (he/him) | I wonder if GHC's configure script still rejects ld.bfd… | 12:44:12 |
| Teo (he/him) | I'd be keen to just make it an opt-in thing for now, and then at some point in the future we can make it the default if we want | 12:49:44 |
 Alex | In reply to @emilazy:matrix.org
OTOH both ld.gold and ld.bfd sort of suck for Linux to be on so maybe someone should make LLD happen system-wide :P I've found mold to be even better than lld.
But it doesn't (didn't?) support the weird things GHC does. :( | 18:24:42 |
