Alex Bennee wrote: > Checking multilib configuration for libmudflap... > mkdir -p -- mips-unknown-linux-gnu/libmudflap > Configuring in mips-unknown-linux-gnu/libmudflap > configure: creating cache ./config.cache > checking build system type... x86_64-unknown-linux-gnu > checking host system type... mips-unknown-linux-gnu > > ^^^ > -- Should this not be my host system, i.e. x86_64-unknown-linux-gnu No. libmudflap is a target library, meaning it is code that runs on the target. So host=$TARGET is correct here. > checking for > mips-unknown-linux-gnu-gcc... /home/alex/src/mips/gcc/gcc-bootstrap/./gcc/xgcc -B/home/alex/src/mips/gcc/gcc-bootstrap/./gcc/ -B/home/alex/src/mips/toolchain/mips-unknown-linux-gnu/bin/ -B/home/alex/src/mips/toolchain/mips-unknown-linux-gnu/lib/ -isystem /home/alex/src/mips/toolchain/mips-unknown-linux-gnu/include -isystem /home/alex/src/mips/toolchain/mips-unknown-linux-gnu/sys-include > checking for C compiler default output file name... configure: error: C > compiler cannot create executables > See `config.log' for more details. > make[1]: *** [configure-target-libmudflap] Error 1 > make[1]: Leaving directory `/home/alex/src/mips/gcc/gcc-bootstrap' > make: *** [all] Error 2 Here you seem to have a problem that the libmudflap configure wants to do a link test to detect features of the target, but you apparently do not have the files that are necessary to link an executable (like crt*.o and libc) yet. The workaround is to configure with a sysroot that contains the items necessary to link. This generally just means copying the libc (headers, libs, *crt*.o, etc.) from an existing system that you're targeting. With linux this is trivial as you can just take them from any distro. Alternatively you can do it in a two step process, where you first build a stripped-down featureless C-only compiler (avoiding steps that want to do link feature tests), then use that to build your libc, then using the results of that rebuild a full-featured gcc with all desired languages. This is sometimes called the crosstool method as it's what's used by the crosstool script. It is good for when you really want to completely bootstrap a system from nothing. A yet third option is available when your target uses newlib, typically embedded boards. You can use --with-newlib and link tests will be skipped and instead a list of known results for newlib will be used. Or you can combine the newlib source in the tree and bootstrap both the compiler and libc at the same time. But again these options only apply to targets that use newlib, not glibc or any other libc; this option isn't a general purpose crutch to get rid of link tests. Philosophically there seems to be a divide as to which route to take. Personally I think if you're targeting a common system (like linux) then you're better off taking a sysroot from an existing system (i.e. unpacking a distro's packages) because they are guaranteed to be tested, stable, and correct -- even better if you plan to use that distro on your actual target hardware eventually because you know there won't be any hidden ABI gotchas. > Also should libmudflap be needed for building kernels? If your only intent for this cross compiler is to build linux kernels, and that is all, then you don't have to worry about any of this. The kernel is standalone, so it doesn't matter if you don't have a libc yet. You can --disable-libmudflap and any other target libraries that require link tests. One thing you may run into is libgcc, which cannot be disabled as it's always required (except for kernels.) You can however bypass building it by using "make all-gcc" instead of "make". The all-gcc target means just build the compiler itself, don't build gcc plus target libraries. (There are similarly prefixed versions of all makefile targets.) Brian
