| 31 Aug 2022 |
 kadokusei10 | And you are correct again,
just confirmed with
$ ldd result/bin/scratch
libc.so => /nix/store/...-musl-1.2.3/lib/libc.so
...
| 14:55:00 |
| kadokusei10 | I was under the impression the allure of pkgsMusl was for building statically, so much so that that was the default when using pkgsMusl, but I was wrong | 14:55:42 |
 cdepillabout | ah, I see | 14:56:02 |
| kadokusei10 | Anyways, thanks for letting me know about haskell-updates building of musl-ghc, I am going to make great use of it :) Good night! | 15:05:06 |
 tristanC | for what its worth, dhall is built using pkgsMusl with these extra configure flags: https://github.com/dhall-lang/dhall-haskell/blob/4763acc7c6d9172bb7e26a990884fa1302eecca7/nix/shared.nix#L282-L294 . | 17:59:21 |
| kadokusei10 | In reply to @tristanc_:matrix.org
for what its worth, dhall is built using pkgsMusl with these extra configure flags: https://github.com/dhall-lang/dhall-haskell/blob/4763acc7c6d9172bb7e26a990884fa1302eecca7/nix/shared.nix#L282-L294 . Thanks! I wonder what is the difference. As I was looking at the build logs from Nix yesterday it looks like choosing pkgsStatic caused everything to be built with musl anyway (i.e. not glibc)
Perhaps using pkgsMusl directly with flags gives one more control?
| 23:47:33 |
| 18 Sep 2022 |
|  imdoor changed their profile picture. | 23:50:40 |
| 26 Sep 2022 |
|  Jonathan King joined the room. | 22:07:03 |
| Jonathan King set a profile picture. | 22:11:12 |
| 5 Nov 2022 |
|  jstranik joined the room. | 00:43:47 |
| 1 Feb 2023 |
|  ribosomerocker joined the room. | 12:30:35 |
| 12 Feb 2023 |
|  @garyalvarez:matrix.org joined the room. | 20:54:34 |
| 13 Feb 2023 |
| @garyalvarez:matrix.org | Redacted or Malformed Event | 00:32:08 |
|  nh2 banned @garyalvarez:matrix.org ("earn money" Spam ). | 05:36:20 |
| 22 Apr 2023 |
|  magnolia_mayhem joined the room. | 04:56:55 |
| 29 Apr 2023 |
|  imlostlmao joined the room. | 19:44:13 |
| 12 May 2023 |
|  @ralph:fx45.in joined the room. | 12:15:04 |
| 20 May 2023 |
| @ralph:fx45.in left the room. | 23:09:18 |
| 29 May 2023 |
| magnolia_mayhem changed their profile picture. | 00:21:25 |
| 13 Jun 2023 |
| Jonathan King | sterni: Hey, hope you’re the right person to ask; at Zurihac while hacking on upgrading things, we discovered that to override GHC you need to do it in two places, both ghc and buildHaskellPackages.ghc — see https://github.com/nh2/static-haskell-nix/pull/116/commits/d90f0ec550a445d489c39a146d2dfd60febb97f2#diff-bc08e3f437e81e48e6466e55a2538708af58937c58337058cfa275d8c58029daR1565
Does this seem the right way to do it and would https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/haskell.section.md be the right place to document this?
We spent quite a while trying to figure this out, so would be good to save others the time in future. | 19:44:22 |
 sterni | Jonathan King: https://github.com/NixOS/nixpkgs/issues/235960; though I would not use overlays to the haskell package set to change GHC, as it is constitutive to it; I'd override it via haskellPackages.override { ghc = …; } although depending on your situation you'd need to pass a separate buildHaskellPackages in as well | 20:07:03 |
| sterni | I'll have to look into how to make this nicer, but honestly since buildHaskellPackages in the end goes back to the nixpkgs fixpoint it seems better to rely on that instead of propagating overlays magically through multiple package sets | 20:08:21 |
| sterni | if you apply your changes via a nixpkgs overlay they should propagate correctly anyways, I think, if you overlay the changed ghc, definitely | 20:08:56 |
| sterni | ah right that's what you are doing | 20:09:56 |
| sterni | in short the thing is that haskellPackages and buildHaskellPackages are independent, yet related, in the native case of course the same, but you need to sure that they are both modified | 20:11:09 |
| sterni | usually it would be easiest to apply the change not to a package set in isolation, but to the nixpkgs fixpoint | 20:11:33 |
| Jonathan King | Yes, so the issue was that when we didn’t override the ghc in buildHaskellPackages (as we didn’t realise it was a thing) and then got confused about having two different versions of GHC (and one without the override we wanted). | 20:12:42 |
| Jonathan King | I’d like to maybe signpost this in some documentation. | 20:13:14 |
| 14 Jun 2023 |
| nh2 | sterni: maybe a helper function overrideGhc that takes a lambda and ensures to apply it on both ghc and the one in buildHaskellPackages would be a good thing? | 00:22:02 |
| sterni | I'm not sure that is a good idea, since it would fall apart in the face of cross compilation, since the lambda would capture only the self fixpoint of the current package set, so package set relative references (buildPackages, self, targetPackages) would be resolved incorrectly for the buildHaskellPackages ghc | 12:38:27 |
