| 2 Feb 2026 |
 alexfmpe | * Technically I expect it should also apply to wasm since these are always 'emulated' targets | 13:29:51 |
| alexfmpe | * Technically I expect it should also apply to wasm (if/when we get it) since these are always 'emulated' targets | 13:30:32 |
 teo (they/he) | Is iserv-proxy rather than just plain iserv needed for these? I would've assumed that iserv-proxy isn't very helpful in nix since you can't access the network | 13:40:52 |
 sterni | we need to execute it independently from ghc anyways since it needs to run under emulation | 14:52:41 |
| teo (they/he) | Sure but isn't that just iserv running under an emulator, does it need to go via a network? | 14:55:09 |
| sterni | no, but can | 15:03:42 |
| teo (they/he) | Ah fair enough then | 15:04:20 |
 hellwolf | https://github.com/NixOS/nixpkgs/pull/486303
&
https://github.com/NixOS/nixpkgs/pull/486009
| 15:17:52 |
| sterni | teo (they/he): you’ll have to ask alexfmpe why exactly but I assume iserv proxy is something that is proven to work for this use case already | 15:26:57 |
| alexfmpe | well, you can still access localhost (though in darwin you either need to disable sandbox or add a magical attribute to the derivation) | 15:37:30 |
| alexfmpe | it doesn't, and IIUC angerman has plans to make it not do that | 15:38:21 |
| alexfmpe | ultimately I just grabbed what haskell.nix uses and shoved it into nixpkgs | 15:38:45 |
| alexfmpe | consider it more of a "upstreamed some of the stuff working over there" than "this is how it should be done" | 15:39:12 |
| alexfmpe | in particular, I think GHC 10.0 is going to change things a bit with the on-demand external interpreter | 15:39:35 |
| teo (they/he) | Sure that makes sense! | 15:39:37 |
| teo (they/he) | Yeah that is quite nice! and is basically just automatically building iserv | 15:40:02 |
| alexfmpe | there's also a lot of miscelanous changes only present in a particular branch of iserv-proxy | 15:40:33 |
| alexfmpe | https://github.com/stable-haskell/iserv-proxy/pull/1 | 15:40:36 |
| alexfmpe | as for iserv, I have no idea where it went after 9.6 | 15:40:43 |
| alexfmpe | https://github.com/NixOS/nixpkgs/pull/445672#discussion_r2430214570 | 15:41:49 |
| teo (they/he) | It lives here https://gitlab.haskell.org/ghc/ghc/-/tree/ghc-9.10/utils/iserv?ref_type=heads but doesn't exist on master since we now use the on demand stuff | 15:44:33 |
| teo (they/he) | iserv-proxy also used to be in the ghc tree but got moved out a while ago | 15:44:57 |
| teo (they/he) | Basically before 10.0, the way to get iserv was to have it bundled with GHC | 15:58:45 |
|  mag changed their display name from m to GOD EMPEROR MAYHEM - OVERSEER OF ENTROPY AND THE SECOND LAW. | 20:38:30 |
| 3 Feb 2026 |
 Alex | This seems to be caused by the unregisterised backend.
I haven't tried an unregisterised native build, but disabling unregisterised "fixed" the build, at the cost of producing segfaulting binaries.
I tried adding -std=gnu17 and even -std=gnu99 to EXTRA_CC_ARGS but I'm still getting errors related to the -std=gnu23 default, so I'm not sure what I'm missing here. | 01:12:03 |
| 4 Feb 2026 |
 Jens Petersen | We have #haskell-distros:matrix.org now btw - just created today if anyone interested | 02:56:49 |
| sterni | In reply to @alex:tunstall.xyz
This seems to be caused by the unregisterised backend.
I haven't tried an unregisterised native build, but disabling unregisterised "fixed" the build, at the cost of producing segfaulting binaries.
I tried adding -std=gnu17 and even -std=gnu99 to EXTRA_CC_ARGS but I'm still getting errors related to the -std=gnu23 default, so I'm not sure what I'm missing here. if all fails we can probably use NIX_CFLAGS_COMPILE | 06:37:31 |
| sterni | I wonder if unregistered builds are affected by this even on later versions | 06:37:59 |
| mag changed their display name from GOD EMPEROR MAYHEM - OVERSEER OF ENTROPY AND THE SECOND LAW to mag. | 13:35:14 |
| Alex | I saw that it gets passed as -optc-std=gnu17. My hypothesis is that -optc options are ignored by the C backend and only used for C source files.
One potential problem with NIX_CFLAGS_COMPILE is that I suspect it would need to be propagated to all dependants.
There might be some other way of configuring C flags, such that they always get used.
I saw for example that --info includes a "CC args" entry, though I'm not sure how the build system sets that. | 17:42:16 |
