ghc: apply arm64 compatibility patch to static gmp

[claui]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

This is a work in progress following up on @BytesGuy’s comment.

In an attempt to get ghc building, this PR applies the known GMP patch to the static GMP resource.
This part works for me; the static GMP gets built into libexec/integer-gmp.

However, the build then proceeds to fail, due to a different thing which is confusingly also called integer-gmp. The latter is a vendored dependency that comes with ghc’s source tree, and seems to be a separate piece of software which is only loosely related to GMP. That one still breaks, and I need some help to finish this because I’ve already spent way too much time on it.

Steps to reproduce:

1. On macOS 11 beta (Apple Silicon), check out this PR.
2. Run brew install -ds ghc and watch it fail.
3. Select shell to get dumped into the shell.
4. Acknowledge that there’s now a directory called libraries/integer-gmp (sic).
5. cd to libraries/integer-gmp/gmp/gmpbuild/mpn.
6. Run the following command line to reproduce the error (and to show that the vendored integer-gmp still needs to be convinced we’re on arm64):

../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="/usr/bin/m4" clang -c -DHAVE_CONFIG_H -I. -I..  -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add_n | sed 's/_$//'`   -fno-stack-check  `test -f 'add_n.asm' || echo './'`add_n.asm

What really confuses me here is: why do we name the prefix (to which we’re compiling the static GMP resource) libexec/integer-gmp? Why even name it like that, despite the fact that build process goes on to use an unrelated, vendored-in-its-source-tree, eponymous thing anyway?

See also:

• The GMP patch we’re using
• The original PR that applied the patch to Homebrew’s gmp

[BytesGuy]

@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 🙂

[BytesGuy]

@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]

@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 —.)

[BytesGuy]

@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!

[BytesGuy]

@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

[claui]

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

[BytesGuy]

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

[claui]

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.

[claui]

Needs rebase once #59361 is merged.

[claui]

Still committed to this.

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

[hjelmn]

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?

[claui]

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 🎉

[hjelmn]

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.

[hjelmn]

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.

[claui]

Thank you so much for your work @hjelmn!

[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.

[aryairani]

Thanks everyone!

[hjelmn]

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

[hjelmn]

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.