stack setup installs GHC for aarch64 on M1 Macs
#5562
Conversation
|
Got this output: Regardless of the error message above, And if I try to use |
|
@yairchu Have you tried installing LLVM? (e.g. I wonder if Stack will end up having to manage LLVM installations, since in the past different versions of GHC have required different LLVM versions. This has been a barrier to full ARM support on Linux. |
|
It appears I've already had llvm installed via brew, so I tried upgrading it to 12.0.0_1, and got interesting output: So following the above message I've tried running |
|
I can report that I'm having the same issue as @yairchu, with the same output. Stack is first reporting that the GHC failed to compile a sanity check. This seemed a little odd, so I ran the same GHC version myself. I first created a source file with the contents I think are the same as the sanity check: import Distribution.Simple
main = putStrLn "Hello World"I ran this through the GHC that stack indicated it used to compile the sanity check: Adding the LLVM location to Whilst it complains about the LLVM version, it still links an arm64 executable that runs as expected. I must be missing something that stack is doing to the environment or something similar. |
|
It seems I can reproduce the output for the failed sanity check when I run GHC with |
|
If you omit the I suspect that because you're using an x86 |
|
Hi @borsboom, when I run without the (full output is here) I agree that the issue is likely due to the propagation of Rosetta. I had similar issues with other software before their Apple Silicon version (e.g. VSCode). |
|
My M1 setup has Rosetta removed. My stack binary is built with native ghc and cabal. It seems working well. Will Stackage add 8.10.5 support? |
|
@ncihnegn |
|
@ncihnegn Are you able to build the stack project itself using the |
Not at all. I tried changing resolver in stack.yaml to ghc-8.10.5 and adding packages in stack.yaml.lock to extra-deps. But there are still compiling errors in pantry. |
It is ghc who complains about LLVM version. |
|
It appears that if I change (added the then another invocation of |
After I dump the dependency from plan.json into extra-deps, I can build the stack project. So stack itself is fine. What is missing is Stackage support. |
|
@ncihnegn I don't suppose you could upload the M1 |
You may want to use the native haskell-stack bottle in homebrew. |
|
I have a mac M1 without rosetta2 installed. I built this branch locally using stack from brew and everything appears to work as I would expect:
(Edited to make it easier to read) |
borsboom
force-pushed
the
macosx-aarch64
branch
from
0cd68aa to
65bb9a5
Compare
|
I'm going to merge this because there don't seem to be any effects on pre-existing behaviour, but it does improve the situation for Mac M1 users who aren't using Rosetta2. |
|
Chiming in here with what worked for me in case it's helpful for others who find this issue:
export PATH="/opt/homebrew/opt/llvm/bin:$PATH"
export LDFLAGS="-L/opt/homebrew/opt/llvm/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm/include"
Now you have stack installed under Update: So this works, and you CAN compile code with this, but it's incredibly slow. |
I was curious if I could reproduce this slow-down, but I was not able to. I compiled unison on an M1 mac mini (8GB ram) and it took under 20 minutes. The only difference I see is that I used ghc from brew to compile stack as shown in my comment above, instead of ghcup. I rebuilt stack using the master branch (708b516) and then proceeded to make sure I was using the executable that I just built. The master branch build of stack can now download ghc for M1. with
|
ghcup uses the official GHC binary distribution and so does the brew formula for bootstrapping: https://github.com/Homebrew/homebrew-core/blob/996835f510d4084f6a2c31a1353887945ba2cf45/Formula/ghc.rb#L54 Could you please test whether the builds are slower with the GHC upstream provided bindist? I doubt it, because we would have seen this in CI, but who knows. |
tl;dr
details
Note that the brew vs ghcup difference is only used to compile stack, not unison. The ghc used for unison is the one that stack downloads for aarch64-osx, which also matches what brew and ghcup use.
Which URL does this correspond to? I downloaded the archive from the CI job https://gitlab.haskell.org/ghc/ghc/-/jobs/772824 and unzipped/untarred the archive: Then went back to unison I wasn't sure which ghc it was actually using, so I re-ran with |
|
For anyone reading this thread looking to get Stack + GHC up and running natively on Apple Silicon before the next Stack version is released, installing the recentmost Stack from source using Homebrew did work for me (this will install LLVM 12 automatically): brew install --HEAD haskell-stackCompiling with GHC however yielded the following error message: The solution here is to make sure the LLVM 12 installation that brew installed earlier is on the PATH (note the use of export PATH="/opt/homebrew/opt/llvm@12/bin:$PATH"
export LDFLAGS="-L/opt/homebrew/opt/llvm@12/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@12/include" |
|
For anyone reading this thread, Until then, you can use my patched version of stack like this: Reference |
- Fixed building from source. Due to recent update of aeson-2.0.0.0, stack can no longer be built with cabal-install. So I patched stack to freeze cabal dependencies using stackage 17.15 LTS. - Add Apple Silicon support. HEAD version of stack has already been patched to support Apple Silicon. However, the next release containing that patch hasn't release yet. So I manually patched stack v2.7.3 to support Apple Silicon. - Add llvm@12 as a dependency only on ARM All ghc versions before 9.2.1 requires LLVM Code Generator as a backend on ARM. Fixes Homebrew#94796 Reference: commercialhaskell/stack#5562 commercialhaskell/stack#5677
- Fixed building from source. Due to recent update of aeson-2.0.0.0, stack can no longer be built with cabal-install. So I patched stack to freeze cabal dependencies using stackage 17.15 LTS. - Add Apple Silicon support. HEAD version of stack has already been patched to support Apple Silicon. However, the next release containing that patch hasn't release yet. So I manually patched stack v2.7.3 to support Apple Silicon. - Add llvm@12 as a dependency only on ARM All ghc versions before 9.2.1 requires LLVM Code Generator as a backend on ARM. Fixes #94796 Reference: commercialhaskell/stack#5562 commercialhaskell/stack#5677
THIS IS UNTESTED because I don't have an M1 Mac. However,
stack --arch=aarch64 --resolver=ghc-8.10.5 setupdoes download the correct bindist and tries to install it on my Intel Mac (but of course this fails with "Bad CPU type in executable").Note: this will only work with GHC 8.10.5 right now, since that's the only GHC version with an aarch64 bindist for macOS. You can use
stack --resolver=ghc-8.10.5 setupto test.One potential downside of this change:
stack setupon M1 Macs will not, by default, work with any GHC <8.10.5, since there aren't aarch64 bindists available (before this change,stack setupalways uses the x86 bindist even on M1 Macs, so this wasn't an issue). Users will have to use--arch=x86_64to force the use of Rosetta. Mac users are pretty accustomed to system or OS upgrades breaking old GHC versions, so not sure if this matters.We could potentially implement automatic fallback to x86, if that turns out to be desirable. I personally think I would want to explicitly enable Rosetta emulation if I had an M1 Mac, but I could see others preferring it to be implicit and I'm not sure there's a really clear case to be made for either way. There will almost certainly come a day when Apple completely stops supporting Intel, even through emulation (as they did with PowerPC and Motorola 68000), at which point a fallback would stop working.