[21.11] haskell.compiler.*: mark as unsupported on aarch64-darwin

[sternenseemann]

While GHC now can be bootstrapped and built on aarch64-darwin, it seems
to work only to an extent. All sorts of strange issues have manifested
themselves in haskellPackages and downstream usage which leads me to
conclude that it would be misleading to call it supported on this
platform, especially in a stable channel. To give a few examples,
separate bin outputs just don't work in general [1] and opt fails
for unknown reasons in some derivations [2]. As I don't own any
appropriate hardware, I have tried tackling these issues by staring into
my crystal ball, but so far to no avail (even worse, new issues [3] have
cropped up due to changes that should have been an improvement).

Given these circumstances, I'm not willing to call GHC supported on
aarch64-darwin for the stable channel. I'm (for now) hopeful that we can
improve the situation on master going forward, but it is not
guaranteed that these changes will be backportable without a ton of
effort.

Should it turn out that we can't resolve these issues or maintain GHC's
aarch64-darwin support due to a lack of contributors going forward, I am
also prepared to drop aarch64-darwin support completely. While it has
been proclaimed a Tier 3 platform, I would argue that the “popular”
package GHC has never been working, at least not properly.

1. haskell packages with separate bin outputs fail due to a reference cycle on aarch64-darwin #140774
2. https://matrix.to/#/!RbXGJhHMsnQcNIDFWN:nixos.org/$C6FK74EajqSTk58JzriYpQJ9f6x3UH3tIREcn04Y-rM?via=nixos.org&via=matrix.org&via=tchncs.de
3. M1 Mac support srid/haskell-template#1 (comment)

Motivation for this change

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[cdepillabout]

This sounds good to me.

Also cc @domenkozar since I think he has contributed some of the fixes for aarch64-darwin.

[domenkozar]

I would like to maintain it so that cachix builds (seems like that was recently broken with llvm). Can we just revert that for aarch64-darwin?

[sternenseemann]

GHC 8.10.7 on aarch64-darwin used LLVM 9 in the past, a version which doesn't support aarch64-darwin fully. As a result shell environments were broken (#147739). It seems it was working before purely by accident before, maybe because a combination of clang 11 and LLVM 9 ended up getting used in the derivation build environment (which is different from the shell environment).

I feel like it might work properly if we use LLVM 11 and clang 11, but this is just a theory at this point. I don't want to ship something I'm not confident in, especially as I (or @NixOS/haskell for that matter) for that matter can do very little to respond to issues or even fix them.

[domenkozar]

cc @NixOS/darwin-maintainers anyone that is interested to help out get GHC working for aarch64-darwin?

[winterqt]

I'm definitely interested (due to the amount of useful tools that are written in Haskell), but I'm not really sure where to begin. If I can be pointed in some direction to start poking in, that would be a great help. (for example: should I try using LLVM/Clang 11 as previously mentioned?)

[reckenrode]

I use hledger on aarch64-darwin. I’m not super familiar with the Haskell ecosystem, but I’d hate to lose native support, so I’d also be willing to help.

[domenkozar]

@sternenseemann any idea what broke things today? https://hydra.nixos.org/job/nixpkgs/nixpkgs-unstable-aarch64-darwin/cachix.aarch64-darwin

[sternenseemann]

@sternenseemann any idea what broke things today? https://hydra.nixos.org/job/nixpkgs/nixpkgs-unstable-aarch64-darwin/cachix.aarch64-darwin

Right, forgot to mention it above apparently. The regression was probably introduced in #147260, my theory is that it has something to do with changing the LLVM version, but I can't be sure. It would be great if someone could do a git bisect and determine which commit in that PR broke haskellPackages.th-abstraction precisely.

Additionally it would be helpful if someone could check log(1) to determine why exactly Setup gets killed.

[CorbanR]

on the latest nixos-unstable , trying to build the nix-darwin system fails.
Specifically when I try running nix-build '<darwin>' -A system --no-out-link.

I am also using a aarch64-darwin system. One of the programs it error's on is haskell package th-compat.

If I try to only install the haskell program with

nix-shell -p "haskellPackages.ghcWithPackages (pkgs: [ pkgs.th-compat ])" -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/master.tar.gz`

I get the following error( see error.txt) the output of nix log ....-th-compat-0.1.3.drv is located in log.txt.

If I pick commit 558da925f33e1b4cb9469997175bf9bdd56586b0 with command

nix-shell -p "haskellPackages.ghcWithPackages (pkgs: [ pkgs.th-compat ])" -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/558da925f33e1b4cb9469997175bf9bdd56586b0.tar.gz

the haskell package builds successfully (and so does my system configuration). This particular commit, only contains some of the changes referenced in #147260

error.txt
log.txt

[thefloweringash]

The error in the logs, Killed: 9, is often a sign of a broken code signature. Skimming through #147260 I see a few places where unwrapped bintools (ie, cctools) are being used directly. Running ld, strip, or install_name_tool without the wrapped version will break the signature. It’s a bit of a guess, I’m waiting on a build to confirm.

[thefloweringash]

The build finished much quicker than I expected. Setting the INSTALL_NAME_TOOL to the wrapped version is sufficient to build haskellPackages.ghcWithPackages (pkgs: [pkgs.th-compat]). Here's the actual patch as a gist. Unfortunately the patch will break x86_64-darwin since there's no wrapper there and the unwrapped version isn't available in ${stdenv.cc}/bin.

The best solution, I think, would be to upgrade cctools for automatic ad-hoc signatures and remove the strip and install_name_tool wrappers. For a more short term fix, we could ensure that install_name_tool is always at ${stdenv.cc}/bin/install_name_tool and use that for ghc. (Or even worse, special case aarch64-darwin in ghc itself).

[sternenseemann]

@thefloweringash Thanks! I seem to recall there was a aarch64-darwin-specific strip wrapper as well, should that also be used?

[sternenseemann]

#148116

[thefloweringash]

@thefloweringash Thanks! I seem to recall there was a aarch64-darwin-specific strip wrapper as well, should that also be used?

Yeah, strip has the same requirements. If it modifies the binary it has to recreate the signature.

[sternenseemann]

Okay, done in 839bcbc8aab8465a78eac7d9a5998d74bbbb5f3c and pushed to that PR as well.

[CorbanR]

@sternenseemann I can also confirm that #148116 has fixed issues I was having with ghc and th-abstraction, thank you!

[domenkozar]

I got a few pings that cachix was broken during that day, so people are using aarch64-darwin ghc packages.

I'm happy to help maintain it.