Nikita Karetnikov <[email protected]> skribis: >> 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:
Yes, because COMPILER_PATH will influence both the native and the cross-compiler. Same problem as discussed at <http://gcc.gnu.org/ml/gcc/2013-02/msg00124.html>. That makes COMPILER_PATH unusable in this context. We need to check how to collect2 finds the cross ld, and adjust our cross-GCC accordingly. (That’s admittedly very vague, but finding out the details is left as an exercise to the reader. ;-)). Thanks, Ludo’.
