Change:
let useLLVM = !stdenv.targetPlatform.isx86; <ins> useNcurses6 = stdenv.hostPlatform.system == "x86_64-linux"; ourNcurses = if useNcurses6 then ncurses6 else ncurses5; </ins> libPath = stdenv.lib.makeLibraryPath ([ <del> ncurses5 gmp </del> <ins> ourNcurses gmp </ins> ] ++ stdenv.lib.optional (stdenv.hostPlatform.isDarwin) libiconv); libEnvVar = stdenv.lib.optionalString stdenv.hostPlatform.isDarwin "DY"

Discussion:
Describe the bug Trying to build GHC 8.8.3 on pkgsMusl (in order to build static Haskell executables) fails with: To Reproduce On a recent pin of nixpkgs-unstable (rev ): Expected behavior GHC 8.8.3 is built based on Musl Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(remo): nixpkgs:
Thanks for creating this issue. Unfortunately, we don't always check to make sure the musl builds succeed before merging stuff in. If you wanted to fix this issue, we'd happily accept a PR. Also, is doing a lot with the musl builds, especially in If you absolutely need a musl'd GHC, I'd suggest to use
To add to that: I pin a nixpkgs that works well in a submodule: ! and the same in the : On the issue: We've seen build failures on latest nixpkgs with musl recently, hopefulyy they will be fixed soon!
Just for the record, current versions of (and ) still have this issue. We'll try to build the package with reverted to check whether the update of the boot compiler caused this problem.
Many thanks all for your help and quick responses! As suggested I reverted and is currently building, getting much further than on ghc865-binary - looking good! I'll update once the build is done, takes quite a bit of time... Edit: Confirmed, successfully built ! I would like to contribute a fix if possible, but I'm not sure what direction would be best to take - GHC 8.8.3 binaries are , would it make sense to bootstrap from there? Edit2: Maybe it just needs in Trying that out right now. Would that be likely to break anything else? Edit3: Couldn't get the dependency from ncurses to work for 8.6.5-binary on pkgsMusl... , I saw that you worked on related things, do you have an idea maybe how to solve this?
CC
It looks to me like this is a bug in the derivation. In particular, the it exposes has the incorrect soname. This is likely because is isn't at all; rather, it's simply a symlink to . In general I don't see how this could work.

We work around this in mpickering/ghc-artefact-nix via
Collecting some info for myself: The derivation refers to (called rather in the issue description) is Question: Do you know what a fix could look like? Instead of a symlink, should it be a copy of the file, on which is subsequently run, as shown in your link? If yes, should that happen unconditionally or only for ? I don't know anything about the ncurses 5-6 switch, so I have no idea why this sophisticated mechanism is there in the first place.
The ideal solution would be to rather use a GHC binary distribution which expects ABI 6. For instance, this patch appears to work around the issue locally:
I have opened to track the symlink issue.
Is it feasible to add to hydra to prevent this from happening?
FWIW this also happens with the ghc-8.10.2 binary used to bootstrap ghc901:
I built things with patch above and it all went very smoothly, is there a reason against including it in nixpkgs, even if just for musl builds?