Re: Correct configure magic for building a MIPS cross compiler

[Brian Dessent <brian at dessent dot net>]

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