| 15 Jul 2025 |
 emily | which sounds like exactly what you want | 20:54:40 |
 JoelMcCracken | yes | 20:54:46 |
 mall0c | one of these days i'll actually deep dive into these magic nix functions (?) or libraries | 20:59:59 |
| 16 Jul 2025 |
 toonn | emily: Why is haskell.nix's approach there cursed? How is the binary supposed to find the dynamic linker if it doesn't patch it to a FHS path? | 08:12:42 |
| emily | there's no guarantee that the FHS glibc is compatible with the Nixpkgs glibc, since the versions differ | 10:26:41 |
| emily | and there's little reason to produce a "mostly-static" binary on Linux since you can just produce a fully-static one | 10:27:00 |
| emily | interacting with GL drivers, maybe… | 10:27:10 |
| toonn | Why would the binary have a reference to the dynamic linker to patch if it was fully static? | 10:33:15 |
| toonn | Maybe it's because of integer-gmp being dynamically linked to avoid license issues? I'm not sure ghc-bignum is the default, especially given the GHC versions haskell.nix supports. | 10:35:00 |
| emily | well, the only reason it's not fully static is because they choose to build it as dynamic | 10:45:42 |
| emily | I can't speak to why they're doing the thing they're doing but I can speak to the fact that it won't reliably work and that it's doing horrible crimes on both Linux and Darwin | 10:46:25 |
| emily | looks like they are specifically using whatever pkgs.static-gmp is | 10:47:01 |
| emily | so I guess there is also plausibly licensing issues to add on to the curse pile | 10:47:19 |
| toonn | If we assume there's a reason it can't be fully static, can they do anything better than patching in an FHS path to the dynamic linker? | 10:53:28 |
| emily | probably using a custom store directory or an unprivileged filesystem namespace and shipping nixGL or something? Nix toolchains aren't designed to produce FHS binaries. | 10:54:28 |
| emily | linking executables to run against random FHS glibcs is horrible in general. | 10:54:52 |
| emily | I believe the consensus solution is "build on a really old version of CentOS". | 10:54:59 |
| emily | https://github.com/input-output-hk/haskell.nix/pull/2157 | 10:56:01 |
| emily | ok wtf. whatever this is is even more horrible | 10:56:06 |
| emily | they're downloading the build products of this to run in builds for IFD? or something? | 10:56:18 |
| emily | so it's not even targeting end-user distribution? | 10:56:41 |
| emily | I'm all in favour of assuming people had good engineering reasons to do something but … | 10:57:25 |
| emily | I bet it's because FODs can't reference the store and they want to download these as prebuilt binaries (as opposed to just using a cache??) and also I assume this requires poking holes in the sandbox so the downloaded thing can access the FHS linker path? | 10:58:51 |
| emily | this PR deletes hundreds of files of generated code that I guess they replaced with this FOD IFD hack? | 10:59:53 |
| emily | I don't want to spend more time thinking about this mess. | 11:00:17 |
| toonn | I guess it cuts down on even evaluating the expressions to find out what to fetch from the cache? | 11:00:47 |
 K900 | iohk people are ... interesting | 11:00:51 |
| emily | my guess is that they either didn't know about pkgsStatic or something in their GHC setup doesn't work with pkgsStatic and they did this instead of fixing that | 11:01:34 |
| emily | tbf they also did this before pkgsStatic worked on Darwin | 11:01:51 |
| emily | they also have conditionals for Windows in the package? even though Nix does not run on Windows. | 11:02:00 |
