The standard way to build a Debian i386->ia64 cross compiler is described in the CrossCompilation page. This page documents a different procedure that ought to get you to roughtly the same place. It might be useful if you're using a different distribution or Debian isn't working (as at 20030429).
Goals
We want to avoid the possibility of messing up the host compiler with the newly installed cross compiler, so everything will be installed under the /opt/ia64 prefix. It can be symlinked from there into /usr/local if you wish, either by hand or by using a tool like stow.
You should make this directory writeable by your regular userid (at least during installation), so that installations don't need to be done by root. This gives an additional protection against accidentally clobbering your native toolchain. Make sure to specify --prefix when configuring so that the programs can find their libraries, definitions, etc.
Ideally we'd like a toolchain that can build both the ia64 kernel and applications, to be run under ski.
Here are the tasks
- build binutils
- build gcc
- build libc
- build gdb
Problems
Here are some problems I don't understand the answer to yet.
- Building gcc seems to need the target's libc headers. But we can't install glibc until we have a cross compiler!
Terminology
For gcc and binutils:
The build system is the system where the GNU tool is being compiled. (Here, it is i386.)
The host system is the system where the tool will run. (Also i386.)
The target system is the system for which the tools should generate code. (Will be ia64.)
The build defaults to the local machine (as detected by config.guess); the host defaults to the build machine; and the target defaults to the host.
For libc, we are compiling code that will run on ia64, so its host will be ia64. (I think.)
Therefore when building the toolchain we just need to specify --target; when building libc we just need to specify --host.
Our destination architecture should always be fully specified as ia64-unknown-linux. Apparently it is better never to abbreviate it.
Generalities
GNU tools like having a separate build directory from the source directory. Make a blank directory for the build, then cd into it before running the configure script.
GNU tools don't have any built scripts in CVS, so you need to prep them with auto* before configuring. Do this in the source directory.
$ libtoolize && automake && autoconf && autoheader
(The particular commands may vary depending on the tree.)
You might like to use ccache and distcc to speed up compilation as some of these programs are pretty big. If you do, make sure that all the machines in your build farm are running consistent versions of the host gcc.
Build binutils
"binutils" is the linker, assembler, objdump, etc: basically all the tools for building programs aside from the compiler itself.
Building the 2.5.67 kernel requires a version of binutils after december 2002. Since there is (as of 2003-04-29) no more recent release, you need to get an anonymous binutils checkout by following the instructions in http://sources.redhat.com/binutils/
Building should be straightforward
$ mkdir build && cd build $ ../src/configure --target=ia64-unknown-linux --prefix=/opt/ia64/ $ make -j5 $ make install
If you look under /opt/ia64 you should see a set of installed tools. At this point it's probably good to put /opt/ia64/bin on your path. All the tools should have fully-qualified names like ia64-unknown-linux-as.
Build gcc
So far, so good. Now to build gcc. I'm using 3.2.3.
We also need to specify a local-prefix for additional header files, as well as a regular GNU prefix. I'll use /opt/ia64/local. The GNU manual warns that this must not be /usr.
To speed the build we'll only enable C and C++
$ mkdir gcc-3.2.3 && cd gcc-3.2.3 $ tar xfz ../gcc-3.2.3.tar.gz && mv gcc-3.2.3 src $ mkdir build && cd build $ CC=gcc-3.2 ../src/configure --prefix=/opt/ia64/ --with-local-prefix=/opt/ia64/local/ \ --target=ia64-unknown-linux --enable-languages=c,c++ $ nice make -j6
At this point, gcc probably stops with something like:
/home/mbp/work/toolchain-ia64/gcc-3.2.3/build/gcc/xgcc -B/home/mbp/work/toolchain-ia64/gcc-3.2.3/build/gcc/ -B/opt/ia64//ia64-unknown-linux/bin/ -B/opt/ia64//ia64-unknown-linux/lib/ -isystem /opt/ia64//ia64-unknown-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_ashrdi3 -c ../../src/gcc/libgcc2.c -o libgcc/./_ashrdi3.o from ../../src/gcc/libgcc2.c:36: ../../src/gcc/config/ia64/linux.h:57:20: signal.h: No such file or directory ../../src/gcc/config/ia64/linux.h:58:26: sys/ucontext.h: No such file or directory
Because we're building on a linux system, we can try using the local system's headers to configure gcc for the target.
Therefore recompile with
$ CC=gcc-3.2 ../src/configure --prefix=/opt/ia64/ --with-local-prefix=/opt/ia64/local/ --target=ia64-unknown-linux \ --enable-languages=c,c++ --with-headers=/usr/include/ $ nice make -j6
This causes gcc's configure script to copy across /usr/include to /opt/ia64/. This probably includes lots of random headers that are not useful (or are incorrect) on ia64. It might be better to get the headers just from libc and the 2.5 kernel source....
This breaks me too, with many errors apparently related to unwinding.
Jes suggests that if you go ahead and do make -k install at this point then you will be able to build the kernel even with a half-broken compiler.
