Why exclude ARM arches here? IIRC, This fiddling is done for ino64 change, which affects all arches.

The code here seems to be contradicting with the comment. You are replacing LOCALBASE with ${PREFIX} instead of setting linker. Can you explain this block?

This also relates to ino64. Doesn't it work for ARM?

Do you plan to upstream these changes to GHC?

My bootstraps binaries are based on FreeBSD 12, they already contains the ino64 change and don't need the 'wrap' hack. It's only needed when the bootstrap compiler is pre ino64 (FreeBSD 10.3 for example).

I want to replace LD_NO_GOLD=ld with LD_NO_GOLD=/usr/local/bin/ld.
I can do @${REINPLACE_CMD} -e 's|LD_NO_GOLD=ld|LD_NO_GOLD=${PREFIX}/bin/ld|' if you prefer (and update aclocal.m4)

I can build the 'wrap' stuff but it's not needed for arm since the bootstraps binaries is post ino64.
I can remove the 'arm' condition if you think the 'if' block is overloaded.

I will try to.

What's LD_NO_GOLD? The linker to be used is set via env var LD. See line 120 of this Makefile.

It can stay, I just making sure there is no hidden problem somewhere.

Please do this for the patches you added and share the link to review on GHC's Phabricator with me.

What's the difference between AC_CHECK_TARGET_TOOL and AC_CHECK_TOOL? Do you plan to upstream this too?

Judging from configure.ac, these can be set with LLC and OPT env vars.

Is this required? How this file is used?

LD_NO_GOLD is just used to speed up some linking phase (ld.gold is slower than 'ld' and 'ld' can be used in some parts of the build without breaking ghc-stage2). Also, our base ld is too old and doesn't work (don't have the error log) so binutils:ld must be used.
USE_GCC overrides LD with /usr/local/bin/ld (line 120 has no effect for arm)

ghc considers armv6 and armv7 as a single arch (called arm) and the configure script thinks that we are cross compiling and searches for cross compile tool. Build and target look like this: build : armv7-unknown-freebsd ; target : arm-unknown-freebsd
I will do the same on our side (ie build: arm-unknown-freebsd).
Thanks for pointing this out.

Didn't know that, many thanks!

I don't know the gory details but it's required when the llvm backend is used (probably to generate code for the correct triple)
I haven't patched utils/llvm-targets/gen-data-layout.sh locally but I'll submit a patch upstream.

If LD_NO_GOLD just speeds the build up, we can move it out of .if ${ARCH} == aarch64 || ${ARCH} == armv6 || ${ARCH} == armv7?

It'll add an extra build dependency for amd64/i386: binutils and I'm not sure it's worth it on those arches.

I don't quite get it. If we already aren't using gold, then setting LD_NO_GOLD should be a no-op, no?

My comment about LD_NO_GOLD is completely wrong, I have mixed up something in my head....

From rules/build-package-way.mk:
NB. LD_NO_GOLD above: see #14328 (symptoms: #14675,#14291). At least
some versions of ld.gold appear to have a bug that causes the
generated GHCi library to have some bogus relocations. Performance
isn't critical here, so we fall back to the ordinary ld

This message gives your opinion and a bad one about qemu. Please make it more neutral.

add a comment saying so.

This is probably wrong, it should be using LOCALBASE and not PREFIX.

It's not my opinion it's the sad reality.

This patch seems to be a duplicate of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228706 no?

No, pr 228706 adds the correct suffix for arm* target. This patch adds the correct compiler flags to build ghc on arm*

${LOCALBASE}/bin/ part shouldn't be needed, just like for opt50.

It does not change the fact that this message is insulting for people who work on qemu.

I work on qemu-user-static and I don't find this message insulting. Feel free to propose something else if you don't like it.

^missing tab aber =

^ could you indent the nested ifs - that makes it a tiny bit more readable.

.if ...
.  if ...

.  endif
.endif

This SIZE line refer ghc-8.4.1, while others are 8.4.2.

maybe add "for this architecture"?

It's already in the 'if ${ARCH}' block, do you think it's needed?

For someone reading the Makefile no; I just assumed someone might see arm64 build log output without noticing that it wasn't amd64. But I suspect it's rather unlikely.