| 2 Jun 2025 |
 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 |
