On Mon, Feb 22, 1999 at 11:09:21AM -0700, Jim Reiss wrote:
> [EMAIL PROTECTED] writes:
> > Current sources are 2.2.1, btw. Updated kernel binaries rsn.
> > Either recompile your kernel without the CONFIG_ROOT_NFS option or pass a
> > root=<root-device> option.
> I believe there is a different kernel option for the BOOTP autoconfiguration
> (CONFIG_IP_PNP).
>
> This is just a suggestion...I think maybe it would be better to first get new
> cross-compiler tarballs with the latest binutils and gcc versions, so that
> users can build their own custom kernels without having to wonder if they
> have properly applied all the patches. Mips and mipsel RPMS with these
> versions would also be helpful, so that if the user successfully installs
> with an old precompiled kernel, they can use that to build the latest sources
> natively. Perhaps these already exist, but I have not seen them.
Note that the crosscompiler binaries out there are somewhat outdated, you'll
have to hack at least the specs file in order to use them. I append the
appropriate chapter on how to build a crosscompiler. The necessary patches
can be extracted from the most current srpm packages, which should be
ftp.linux.sgi.com:/pub/linux/redhat/5.2/ or something like that. float.h
is well, floating around somewhere on the same machine.
Note that you can use any reasonable OS for hosting a crosscompiler, not
just Linux. On non-Linux systems you just may have to install some more
GNU stuff like GNU make, bash etc. I for example do all my crosscompilations
on my Indy running IRIX but an O2000 does a much better job (kernel < 1min)
on it :-).
Any fixes and comments about this crosscompiler howto are appreciated.
> It just seems to me that it's unlikely that many people who know enough to
> install Linux/MIPS will be content with a set of pre-chosen kernel options.
You're probably right.
Ralf
8. How do I setup a crosscompiler?
First of all go and download the following source packages:
o binutils-2.8.1.tar.gz
o egcs-1.0.2.tar.gz
o glibc-2.0.6.tar.gz
o glibc-crypt-2.0.6.tar.gz
o glibc-localedata-2.0.6.tar.gz
o glibc-linuxthreads-2.0.6.tar.gz
These are the currently recommended versions. Older versions may
or may not be working. If you're trying to use older versions
please don't send bug reports, we don't care. When installing
please install things in the order binutils, egcs, then glibc.
Unless you already have older versions already installed changing
the order will fail. The installation description below mentiones
a number of patches which you can get from the respective SRPM
packages on ftp.linux.sgi.com. However since these SRPM packages
are intended to be compiled natively it's not possible to just
rebuild them.
8.1. Diskspace requirements
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 best just 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 binutils on <prefix>'s
partition. Building egcs requires 71mb and installation 14mb. GNU
libc requires 149mb diskspace during installation and 33mb for
installation. Note these number are just a guideline and may differ
significantly for different processor and operating system
architectures.
8.2. Byte order
On 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 the byte
with the highest value digits at the lowest address while little
endian machines store it at the highest address. Think of it like
writing multi digit numbers from the left to the right or visa versa.
In order to setup your crosscompiler correctly you have to know the
byte order of the crosscompiler target. If you don't know already
know, check the section ``Hardware Platforms'' for your machine's
byteorder.
8.3. Configuration names
Many of the packages based on autoconf are supporting many different
architectures and operating systems. In order to differenciate
between these many configurations names madeup like
<cpu>-<company>-<os> or even <cpu>-<company>-<kernel>-<os>. Expressed
that 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. Those names are a bit long and so it's allowed to
abreviate them to mips-linux or mipsel-linux. You must use the same
configuration name for all the packages that your crosscompilation
environment consists of. Also, while other names like mips-sni-linux
or mipsel-sni-linux are both legal configuration names, don't use them
but only mips-linux or mipsel-linux. The reason is that other
packages like the Linux kernel sources know about these configuration
names and you'd have to change them for crosscompilation. I'll refer
to the target configuration name below with <target>.
8.4. Installation of GNU Binutils.
This is the first and most simple 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 install
This 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.
8.5. Assert.h
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 only
got installed due to a bug in older GCC versions. Check if
<prefix>/<target>/include/assert.h exists in your installation. If
so, just delete it. This copy of assert.h should never have been
installed there for any compiler version; the fact that it ever got
installed was a bug in the compiler.
8.6. First installation of egcs
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 yet 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 environe-
ment and protoize and unprotoize might even overwrite your native pro-
grams - this is a bug in the gcc makefiles. Finally we cannot yet
build the libraries because we don't have glibc installed yet. If
everything went successful install with:
make LANGUAGES="c" install
8.7. float.h
Another, bootstrap problem is that building GCC requires running
programs on the machine that GCC will generate code for. But since a
crosscompiler is running on a different type of machine this cannot
work. When buiding 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.h
where <version> is the internal version number of the egcs version
you're using. For egcs 1.0.2 for example you would put egcs-2.90.27
for <version>. If not shure - ls is your friend.
8.8. Installing the kernel sources
XXX Write some simple shit for nobrainers. If you only want the
crosscompiler for building kernel you're done.
8.9. Installing GNU libc
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 sys-
tem's files with Linux/MIPS specific files with desasterous effects.
Instead install GNU libc into some arbitrary other directory <somedir>
from which we'll move the part's we need for crosscompilation into the
actual target directory:
make install_root=<somedir> install
Now cd into <somedir> and install 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 lib -print | cpio -pumd <prefix>/<target>/lib
GNU 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:
step:
cd ../info
gzip -9 *.info*
find . -name \*.info\* -print | cpio -pumd <prefix>/info
If you're not bootstrapping you're installation is now finished.
8.10. Building egcs again
The first attempt of building egcs was stopped by a not yet existent
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 not yet
installed libc. Now install with:
make LANGUAGES="c c++ objective-c f77" install
You're almost finished. All you'll now still have to do is to rein-
stall float.h which has been overwritten by the last make install com-
mand. You'll have to do that 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. However don't build gcov, protoize and unprotoize.
8.11. Should I build the C++, Objective C or F77 compilers?
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 however must build the
C++ compiler because building the libraries included with the egcs
distribution are written in C++.
8.12. GDB
Building GDB as crossdebugger is only of interest to kernel
developers. For them however GDB maybe a live 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. Both are typically interconnected with a
serial line. The target machine's kernel needs to be equiped with a
``debugging stub'' which communicates with the GDB host machine using
the remote serial protocol.
Depending of 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 that
fact that most machines are using similar serial hardware typically
based on the 8250, 16450 or derivates.
XXX Building GDB XXX.
