@claui I'm not at my DTK right now but to try forcing it to build for arm64 have you tried adding --build=aarch64-apple-darwin? Additionally if it fails on some assembly issues a quick fix would be to fall back to a C based build with --disable-assembly until there is an upstream fix. I did try this yesterday and had some success but I may be confusing this with the static GMP resource. Will try poking around with this later this evening 🙂

@claui Following up, how long does it usually take before the install fails? For some reason it is taking 30+ mins and then just hanging for me. Maybe something is messed up in my environment 🤔

@claui Following up, how long does it usually take before the install fails?

@BytesGuy It takes exactly 40 minutes for me before the build fails due to integer-gmp trying to make sense out of x86_64 assembly.

For some reason it is taking 30+ mins and then just hanging for me. Maybe something is messed up in my environment 🤔

What process name is mentioned in the title bar of the terminal window while your build hangs? (It should tell you the process name right next to Terminal —.)

@claui Following up, how long does it usually take before the install fails?

@BytesGuy It takes exactly 40 minutes for me before the build fails due to integer-gmp trying to make sense out of x86_64 assembly.

For some reason it is taking 30+ mins and then just hanging for me. Maybe something is messed up in my environment 🤔

What process name is mentioned in the title bar of the terminal window while your build hangs? (It should tell you the process name right next to Terminal —.)

Ah interesting, perhaps I wasn't leaving it quite long enough. Will give it another go today.

The process was ghc (Intel), seemed to be using a lot of CPU for a long time then just sat there at 0% for an equally long time.

I'm going to clean up my environment and give it another try!

@claui I have managed to reproduce this issue consistently. Unfortunately I cannot seem to find a way around it right now. Basically the issue is similar to the one we saw on the GMP formula in that it is trying to execute x86/_64 assembly natively on arm64 and failing (eax for example is not a valid register on arm64).

My first thought was to try to backport the fix from 6.2.0 to 6.1.2 (the version we are trying to build here), but I'm not sure how feasible that is - I tried applying the patch manually but it didn't work out. Another thought would be to try with --disable-assembly to produce a generic, albeit slow, C build as a temporary workaround - will look into this next

I still don’t understand what that integer-gmp thing is (the vendored one where the error occurs), and whether we even need it.

Looks like it's a library included in GHC which is based on GMP https://hackage.haskell.org/package/integer-gmp So basically looks like a kind of fork of GMP which is configured for the needs of GHC.

Just tried building a generic C build but no luck. The only possible route I could think of now after some research is to switch out integer-gmp for integer-simple. It might work but could be some breaking changes for libraries that specifically require integer-gmp. I guess it would be a good starting point at least until this is fixed upstream. I'll give it a try.

Edit: Not having much luck right now. Going to take a break from this for a bit and focus on some other formulas

One possible way to tackle this is to get integer-gmp building on its own first, and then try and patch it to work with the whole ghc build.

Needs rebase once #59361 is merged.

Still committed to this.

Next step: write a standalone integer-gmp formula and see if that builds correctly.

I have a modification to this formula that builds correctly on aarch64 darwin. Would you like me to open a pull request with the changes?

I have a modification to this formula that builds correctly on aarch64 darwin. Would you like me to open a pull request with the changes?

@hjelmn Amazing, thank you! Yes, please do 🎉

Ok, I am working on cleaning it up. My approach is based off of the iOS cross-compiling support since macOS and iOS are essentially the same.

See
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling/iOS

The approach is to remove gmp 6.1.2 from ghc and replace it with gmp 6.2.1 (fixes compilation on apple silicon) then apply a small patch to fix some of the issues I have seen. This step replaces the external build of gmp. Then it does a quick performance build for aarch64 and uses that result to do a full build. Once ghc releases aarch64 binaries the intermediate step can be skipped.

I should have it ready today. Can probably apply the same approach to 8.10.

That took more time than expected. I finally got it fully build but it required installing clang/llvm 7.1.0 (needed for the cross-compile step). So, I will open a PR but hopefully ghc gets a binary release done before too long. Building ghc twice takes awhile.

Thank you so much for your work @hjelmn!

No problem. I verified the procedure works with a hand-built llvm@7. The brew formula does not build. Will see if that is being worked on. May have to fix that first.

Thanks everyone!

Opened #65628 to address llvm@7 build. Will start testing the ghc@8.8 formula with this build.

ghc 8.8 may be a lost cause for Apple Silicon. I patched the code and build system with some changes from ghc master to fix the build but after running it for a couple of days I ran into an issue with the linker code (pandoc fails to build). I confirmed the issue is fixed in 8.10.2 but the patch may be more difficult to backport to 8.8.4 than the other patches. I was able to get a patched 8.10.2 to build with llvm 11 and will focus on getting that formula working. In order to switch to 8.10 and deprecate 8.8 in homebrew cabal-install 3.4.0.0 is needed. Once ghc 8.10 is fixed I will see what I can do to update the cabal-install formula.