First of all go and download the following source packages:
For the installation you'll have to choose a directory for installation. I'll refer to that directory below with <prefix>. To avoid a certain problem it's best to use the same value for <prefix> as your native gcc. For example if your gcc is installed in /usr/bin/gcc then choose /usr for <prefix>. You must use the same <prefix> value for all the packages that you're going to install.
During compilation you'll need about 31mb diskspace for binutils; for installation you'll need 7mb diskspace for on <prefix>'s partition. Building egcs requires 71mb and installation 14mb. GNU libc requires 149mb diskspace during compilation and 33mb for installation. Note these numbers are just a guideline and may differ significantly for different processor and operating system architectures.
One of the special features of the MIPS architecture is that all processors except the R8000 can be configured to run either in big or in little endian mode. Byte order means the way the processor stores multibyte numbers in memory. Big endian machines store the byte with the highest value digits at the lowest address while little endian machines store it at the highest address. Think of it as writing multi-digit numbers from left to right or vice versa.
In order to setup your crosscompiler correctly you have to know the byte order of the crosscompiler target. If you don't already know, check the section Hardware Platforms for your machine's byteorder.
Many of the packages based on autoconf support many different architectures and operating systems. In order to differentiate between these many configurations, names are constructed with <cpu>-<company>-<os> or even <cpu>-<company>-<kernel>-<os>. Expressed this way the configuration names of Linux/MIPS are mips-unknown-linux-gnu for big endian targets or mipsel-unknown-linux-gnu for little endian targets. These names are a bit long and are allowed to be abbreviated to mips-linux or mipsel-linux. You must use the same configuration name for all packages that comprise your crosscompilation environment. Also, while other names like mips-sni-linux or mipsel-sni-linux are legal configuration names, use mips-linux or mipsel-linux instead; these are the configuration names known to other packages like the Linux kernel sources and they'd otherwise have to be changed for crosscompilation.
I'll refer to the target configuration name below with <target>.
This is the first and simplest part - at least as long as you're trying to install on any halfway-sane UNIX flavour. Just cd into a directory with enough free space and do the following:
gzip -cd binutils-<version>.tar.gz | tar xf - cd binutils-<version> patch -p1 < ../binutils-<version>-mips.patch ./configure --prefix=<prefix> --target=<target> make CFLAGS=-O2 make installThis usually works very easily. On certain machines using GCC 2.7.x as compiler is known to dump core. This is a known bug in GCC and can be fixed by upgrading to GCC 2.8.1 or egcs.
Some people have an old assert.h headerfile installed, probably a leftover from an old crosscompiler installation. This file may cause autoconf scripts to fail silently; it was never necessary and was only installed because of a bug in older GCC versions. Check to see if the file <prefix>/<target>/include/assert.h exists in your installation. If so, just delete the it: it should never have been installed.
Now the not-so-funny part begins: there is a so-called bootstrap problem. In our case that means the installation process of egcs needs an already- installed glibc, but we cannot compile glibc because we don't have a working crosscompiler yet. Luckily you'll only have to go through this once when you install a crosscompiler for the first time. Later when you already have glibc installed things will be much smoother. So now do:
gzip -cd egcs-<version>.tar.gz | tar xf -
cd egcs-<version>
for i in egcs-1.0.2-libio.patch egcs-1.0.2-hjl.patch \
egcs-1.0.2-rth1.patch egcs-1.0.2-rth2.patch egcs-1.0.2-rth3.patch \
egcs-1.0.2-rth4.patch egcs-1.0.2-hjl2.patch egcs-1.0.2-jim.patch \
egcs-1.0.2-haifa.patch egcs-1.0.1-objcbackend.patch \
egcs-1.0.2-mips.patch; do patch -p1 -d < ../$i; done
./configure --prefix=<prefix> --with-newlib --target=<target>
cd gcc
make LANGUAGES="c"
Note that we deliberately don't build gcov, protoize, unprotoize and the
libraries. Gcov doesn't make sense in a crosscompiler environment and
protoize and unprotoize might even overwrite your native programs - this
is a bug in the gcc makefiles. Finally we cannot build the libraries
because we don't have glibc installed yet. If everything went successfully,
install with:
make LANGUAGES="c" install
Another bootstrap problem is that building GCC requires running programs on the machine for which GCC will generate code, but since a crosscompiler is running on a different type of machine this cannot work. When building GCC this happens for the header file float.h. Luckily there is a simple solution: download the header file from one of the Linux/MIPS ftp servers or rip it from one of the native Linux/MIPS binary packages. Later when recompiling or upgrading egcs usually the already-installed float.h file will do because float.h changes rarely. Install it with:
cp float.h <prefix>/<target/<version>/include/float.hwhere <version> is the internal version number of the egcs version you're using. For egcs 1.0.2 for example you would use egcs-2.90.27 for <version>. If not sure - ls is your friend.
Installing the kernel sources is simple. Just place them into some directory of your choice and configure them such that some files which are generated by the procedure will be installed. This works the same as you're used to when configuring the kernel sources for native compilation. The only problem you may run into is that you may need to install some required GNU programs like bash or have to override the manufacturer-provided versions of programs by placing the GNU versions earlier in the PATH variable. When configuring you should answer the question ``Are you using a crosscompiler'', that is the option CONFIG_CROSSCOMPILE, with ``yes''. When you're done with configuring type make clean; make depend; make. The last make command will generate the header file <linux/version.h> which compiling some programs depends on. This file is generated right at the beginning of the make command, so if you're not interested in actually building a kernel you may interrupt the compilation after this file has been built. It may be a good idea, however, to compile the kernel as a test for your newly-built crosscompiler.
If you only want the crosscompiler for building the kernel, you're done. Crosscompiling libc is only required to be able to compile user applications.
Do:
gzip -cd glibc-2.0.6.tar.gz | tar xf -
cd glibc-2.0.6
gzip -cd glibc-crypt-2.0.6.tar.gz | tar xf -
gzip -cd glibc-localedata-2.0.6.tar.gz | tar xf -
gzip -cd glibc-linuxthreads-2.0.6.tar.gz | tar xf -
patch -p1 < ../glibc-2.0.6-mips.patch
mkdir build
cd build
CC=<target>-gcc BUILD_CC=gcc AR=<target>-ar RANLIB=<target>-ranlib \
../configure --prefix=/usr --host=<target> \
--enable-add-ons=crypt,linuxthreads,localedata --enable-profile
make
You now have a compiled GNU libc which still needs to be installed. Do
not just type make install. That would overwrite your host
system's files with Linux/MIPS-specific files with disastrous effects.
Instead install GNU libc into some other arbitrary directory <somedir>
from which we'll move the parts we need for crosscompilation into the
actual target directory:
make install_root=<somedir> installNow cd into <somedir> and finally install GNU libc manually:
cd usr/include find . -print | cpio -pumd <prefix>/<target>/include cd ../../lib find . -print | cpio -pumd <prefix>/<target>/lib cd ../usr/lib find . -print | cpio -pumd <prefix>/<target>/libGNU libc also contains extensive online documentation. Your systems might already have a version of this documentation installed, so if you don't want to install the info pages, which will save you a less than a megabyte, or already have them installed, skip the next step:
cd ../info gzip -9 *.info* find . -name \*.info\* -print | cpio -pumd <prefix>/infoIf you're not bootstrapping your installation is now finished.
The first attempt of building egcs was stopped by lack of a GNU libc. Since we now have libc installed we can rebuild egcs but this time as complete as a crosscompiler installation can be:
gzip -cd egcs-<version>.tar.gz | tar xf -
cd egcs-<version>
for i in egcs-1.0.2-libio.patch egcs-1.0.2-hjl.patch \
egcs-1.0.2-rth1.patch egcs-1.0.2-rth2.patch egcs-1.0.2-rth3.patch \
egcs-1.0.2-rth4.patch egcs-1.0.2-hjl2.patch egcs-1.0.2-jim.patch \
egcs-1.0.2-haifa.patch egcs-1.0.1-objcbackend.patch \
egcs-1.0.2-mips.patch; do patch -p1 < ../$i; done
./configure --prefix=<prefix> --target=<target>
make LANGUAGES="c c++ objective-c f77"
As you can see the procedure is the same as the first time with the
exception that we dropped the --with-newlib option. This option was
necessary to avoid the libgcc build breaking due to the lack of
libc. Now install with:
make LANGUAGES="c c++ objective-c f77" installYou're almost finished. All you have left to do now is to reinstall float.h, which has been overwritten by the last make install command. You'll have to do this every time you reinstall egcs as a crosscompiler. If you think you don't need the Objective C or F77 compilers you can omit them from above commands; each will save you about 3mb. Do not build gcov, protoize or unprotoize.
The answer to this question largely depends on your use of your crosscompiler environment. If you only intend to rebuild the Linux kernel then you have no need for the full blown setup and can safely omit the Objective C and F77 compilers. You must, however, build the C++ compiler, because building the libraries included with the egcs distribution requires C++.
Building GDB as crossdebugger is only of interest to kernel developers; for them GDB may be a life saver. Such a remote debugging setup always consists of two parts: the remote debugger GDB running on one machine and the target machine running the Linux/MIPS kernel being debugged. The machines are typically interconnected with a serial line. The target machine's kernel needs to be equipped with a ``debugging stub'' which communicates with the GDB host machine using the remote serial protocol.
Depending on the target's architecture you may have to implement the debugging stub yourself. In general you'll only have to write very simple routines for serial. The task is further simplified by the fact that most machines are using similar serial hardware typically based on the 8250, 16450 or derivatives.