> You mean it _tries_ to use it, because it’s not available in chroot
> builds, right?

It'll try to use '/usr/bin/ld' if I run 'unset COMPILER_PATH'.  I guess
that it's trying to autodetect the right linker during './configure'.

However, if I run

export COMPILER_PATH=/nix/store/khdyz3i5aih56lxfk6hjvp3884apm7qb-gcc-cross-mips64el-linux-gnu-4.7.2/libexec/gcc/mips64el-linux-gnu:/nix/store/khdyz3i5aih56lxfk6hjvp3884apm7qb-gcc-cross-mips64el-linux-gnu-4.7.2/libexec/gcc/mips64el-linux-gnu/4.7.2

to specify the location of subprograms, it'll complain about
unrecognized opcodes.  For example:

configure: Building in-tree ghc-pwd
/tmp/ghc30831_0/ghc30831_0.s: Assembler messages:

/tmp/ghc30831_0/ghc30831_0.s:23:0:
     Error: Unrecognized opcode `cmpl $92,3(%esi)'

/tmp/ghc30831_0/ghc30831_0.s:24:0:
     Error: Unrecognized opcode `jne .LcF1'

> Perhaps it needs both a native GCC and a cross-GCC (ditto for ‘ld’), no?
> (For instance because ghc-pwd is a program to run during the build, so
> it needs to be a native program.)

I think that it's the reason for the above messages, but I can't say for
sure.

> Does it have --with-target-gcc or similar in addition to --with-gcc?

No.  Is there a workaround (e.g., envvars)?