Moritz Angermann

We try to not have patches in here that regress. We might be able to drop the ubxt patch, we will need to see how that impacts performance though. For...

We haven't decided on the exact plan yet. Just that we want to put the unpatched ones in. Something like ghc-NNN-iohk might be an option.

> When I first saw this issue I thought that using the unpatched compiler would be equivalent to using a vanilla compiler from Nixpkgs, but that isn't the case right?...

What you are seeing is effecitvely the cross compilation pipeline for TH to fail. Unless you are absolutely in need to target 32bit raspberries, I'd sugest to just go with...

Alright, so this is effectively only a single additional patch. 🤔

@rtimush interesting. So we fail to build `lib:ghc` with `-DGHCI` I guess you could alternatively do ``` { packages.ghc.ghc-options = "-DGHCI"; } ``` or ``` { packages.ghc.flags.ghci = true; }...

At least in head there is no `GHCI` ifdef anymore: https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcPluginM.hs

@roberth the first issue with lib-ghc failing sounds like the the ghci-flag is not picked up correctly. That is rather confusing. Do you happen to have the full log for...

The following change seems to have resolved the issue @roberth has been seeing: ``` packages.ghc.flags.ghci = pkgs.lib.mkForce true; packages.ghci.flags.ghci = pkgs.lib.mkForce true; ```

Stripping will mostly break LLVM build macOS builds. We _try_ to remove `.deadstrip_via_symbols` from the assembly these days. The issue (at least on darwin is as follow; due to Table...