> 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)?
pgpVXAFUBWLBS.pgp
Description: PGP signature
