/cc ZHF #80379

cc @Ericson2314 and @matthewbauer. I think you guys use GHC on alternative architectures, so hopefully you'll know whether this is a reasonable fix.

@cdepillabout should this target haskell-updates since it's haskell related?

@disassembler We often ask that changes to stuff in pkgs/development/haskell-modules/ go to the haskell-updates branch, but we're not as strict about changes to pkgs/development/compilers/ghc. Let's wait and see what @Ericson2314 / @matthewbauer / @peti have to say about this PR.

That said, rebasing this on haskell-updates wouldn't be a problem for us.

Looks good to me.

From past experience, not using the "blessed" llvm version is likely (but not guaranteed, hence the warning) to work, especially if using a later version of llvm. Testing this PR, I have successfully built a working ghc865 on aarch64. I think this probably means that it's ok to ignore the warning on the basis that:

1. GHC is a fairly large and complex haskell package: The fact that we can build it is a reasonably good test of whether the GHC with mismatched llvm is functional.
2. We are slightly distanced from the mismatched ghc+llvm because while it was used to compile ghc865, ghc865 has it's own, correct, version of llvm.

I still can't see exactly what changed/why it worked without propagating llvm before. Is it possible that the ghc822Binary was able to function because it was finding the opt and llc binaries from the buildInputs of the package it was building? That might make sense for building ghc865, which has llvm in its buildInputs, but I can't see why the hscolour build would have opt and llc in its system path if not propagated from ghc822Binary.

Let me know if there's anything else you'd like me to test with said build of ghc865.

Looks like the other (compiled from source) ghc packages add llvm to depsBuildTarget. Would that be an appropriate place to put it for ghc822Binary too?

I tried adding llvm to depsBuildTarget; it doesn't seem to work.

@peti I'm not sure if I've understood correctly. Are you suggesting that packages which depend on ghc822Binary should be responsible for adding llvm to their buildInputs instead (on platforms where it's required)?

Yes, that's my understanding of the comment.

It's an unusual situation, in that ghc822Binary is only really there to bootstrap other GHC builds, but isn't it a bit odd to have a compiler package which can't compile anything on its own?

Is it even possible to make hscolour depend on llvm when built by ghc822Binary on aarch64?

Certainly sounds possible to me.

I don't think that propagatedBuildInputs is the right place to add llvm. I'd prefer if those builds that need LLVM (on certain) platforms express that dependency explicitly.

It's my understanding that the builds that need LLVM are exactly "things built with ghc822Binary on arm". On current master, for example, trying to build a basic Haskell hello world without nix:

$ cat Test.hs
main = putStrLn "Hello, World!"

$ nix run -f . haskell.compiler.ghc822Binary -c ghc -c ./Test.hs
# [ trimmed warnings ]
<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM 3.9
ghc: could not execute: opt

It seems to be a runtime dependency of ghc resolved via PATH. propagatedBuildInputs doesn't exactly capture that. In general it's the kind of thing that would go in a wrapper, is that safe to to apply here?

My motivation for opening this was to restore ghc on aarch64 by fixing its bootstrap ghc. Since the version of ghc in current master (8.8.x) no longer bootstraps via ghc822Binary there's not as much to be gained by fixing ghc822Binary on aarch64. Should I go ahead and close this, even though it remains broken? If not, how can we progress this?

It would be a shame not to have a working aarch64 GHC in 20.03. In the absence of a more 'correct' solution, would it make sense to put this into 20.03, but not into master?

This objection is silly to me. All of the non-bootstrap GHCs have LLVM (optionally) in propagatedBuildInputs. Maybe it's good, maybe it's bad, but it's certainly consistent, and consistency is good. Let's make it consistent and then make it better.

I pushed a small tweak to make it have a structure closer to the non-bootstrap compilers.

All of the non-bootstrap GHCs have LLVM (optionally) in propagatedBuildInputs. Maybe it's good, maybe it's bad, but it's certainly consistent, and consistency is good. Let's make it consistent and then make it better.

I'd prefer we make it better. propagatedBuildInputs is not the right place for LLVM. If a platform requires that compiler, then the dependency should be configured in the generic builder, not in the compiler.

@peti I agree that it would be great for it to be made better, but I think it is somewhat out of scope for this PR.

I think it is reasonable to merge this in as-is (since it appears to just be making things consistent), and then correct all these uses of LLVM in a future PR.

I guess we can close this PR since the change is now part of #83164 and will be merged into master next Friday.

I think this PR is updating ghc822Binary, while #83048 is doing the same for ghc865Binary. It looks like #83048 has already been merged into haskell-updates, but this PR still needs to be merged in.

@thefloweringash Is this correct?

I think this PR is updating ghc822Binary, while #83048 is doing the same for ghc865Binary. It looks like #83048 has already been merged into haskell-updates, but this PR still needs to be merged in.

@thefloweringash Is this correct?

Yep. I've been chasing the bootstrap compiler to bring ghc back to aarch64. On current master that's ghc865Binary which is now part of haskell-updates from #83048. For release-20.03 it's ghc822Binary which is this PR. If this is merged, we should back port to 20.03.

@GrahamcOfBorg build haskell.compiler.ghc865

This PR doesn't affect linux nor darwin, so it's safe to merge into master. In current state it can't make aarch64 worse.

I moved my today's (confused) comments to a better thread: #66277