Wiki > Main > CrossCompiler (compare)
Difference: CrossCompiler (r104 vs. r103)
In this example it will be assumed that you are running Linux with the bash shell (or cygwin). We will only build the C compiler along with the assembler, linker and stuff. Note that the procedure is exactly the same if you are running cygwin on Windows, and on Macintosh OS X.
The Archos Jukebox and Ondio models have an SH-1 CPU, so the target name is sh-elf.
The iriver H-xxx, iAudio X5 and M5 models have a Coldfire CPU, so the target name is m68k-elf.
The iPod, iriver IFP-7x0, iriver H10, m:robe, Sansa e200/c200/fuze/clip, D2, YH-xxx and Gigabeat F/X/S builds have ARM cores, so the target name is arm-elf-eabi.
Note: The rest of this tutorial describes how to build the SH-1 cross compiler. To build a ColdFire, or ARM compiler, substitute sh-elf with your target name from above in the --target parameter, and use another path in the --prefix parameter as well.
In the tools/ directory of your checked out Rockbox source code, there's this shell script called rockboxdev.sh that will perform the cross-compiler installation for you fully automatically.
When run, it will first prompt you for what architecture to build for, and then it'll proceed to download, unpack, build and install both binutils and the proper gcc version for you. If necessary it will even patch gcc accordingly.
All compilers are installed to /usr/local/bin, which is usually in your PATH already. If it isn't, add it to the .bashrc file in your home directory.
When using this script, you do not need to follow the rest of this instruction below this point. That is only for pure manual installation.
Note for Ubuntu users: you will need build-essential and texinfo installed: sudo apt-get install build-essential texinfo
Note for Cygwin users: the script may take up to 6-8 hours to complete, depending on your CPU
Note for systems that have /tmp in ram: change the temp path at the top of rockboxdev.sh to avoid running out of space
Below is a list of stuff that must be installed before starting:
for arm-app (Samsung ypr0) only:
Note that the automatic build using rockboxdev.sh is strongly recommended. If automatic building doesn't work, ask for help on the forums or raise a bug.
Note: These manual instructions describe how to build the SH-1 cross compiler (sh-elf). To build a ColdFire, or ARM compiler, substitute sh-elf with your target name from above in the --target parameter, and use another path in the --prefix parameter as well.
Instructions here might be obsolete. as nobody does it manually really.
You will need the following archives:
Note: We know that there are newer versions of gcc/binutils available. See the last paragraph in this document.
NOTE: rockboxdev.sh downloads these patches automatically - you do not need to download them separately if you're running rockboxdev.sh
Note: For better (read: smaller) code, apply the patch gcc-3.4.6-rockbox-2.diff below. It changes how gcc selects between using multiplication and shift-and-add for some calculations. (It is a bit of a hack, because it affects more target CPU models than it should. Not a problem as long as you only use the compiler for Rockbox development.) - MagnusHolmgren
[Linus-Computer:~] linus% bash
(some may need to get the sources off CVS servers, as noted above)
/home/linus> tar xvjf binutils-2.16.1.tar.bz2 /home/linus> tar xvjf gcc-core-4.0.3.tar.bz2 /home/linus> tar xvjf gdb-6.6.tar.bz2
Apply patches if necessary (see the table above)
/home/linus> patch -p0 <gcc-4.0.3-rockbox-1.diff
/home/linus> mkdir build /home/linus> cd build /home/linus/build> mkdir binutils /home/linus/build> mkdir gcc /home/linus/build> mkdir gdb
Now is the time to decide where you want the tools to be installed. This is the directory where all binaries, libraries, man pages and stuff end up when you do "make install".
In this example I have chosen "/home/linus/sh1" as my installation directory, or prefix as it is called. Feel free to use any prefix, like /usr/local/sh1 for example.
We will start with building the binutils (the assembler, linker and stuff). This is pretty straightforward. We will be installing the whole tool chain in the /home/linus/sh1 directory.
If you are building on a Macintosh OS X machine, you have to disable the precompiled headers:
/home/linus> export CC="gcc -no-cpp-precomp"
Then configure, make and install:
/home/linus> cd build/binutils /home/linus/build/binutils> ../../binutils-2.16.1/configure --target=sh-elf --prefix=/home/linus/sh1 /home/linus/build/binutils> make /home/linus/build/binutils> make install
Now you are ready to build GCC. To do this, you must have the newly built binutils in the PATH.
Then set the PATH, configure and make:
/home/linus> export PATH=/home/linus/sh1/bin:$PATH /home/linus> cd build/gcc /home/linus/build/gcc> ../../gcc-4.0.3/configure --target=sh-elf --prefix=/home/linus/sh1 --enable-languages=c /home/linus/build/gcc> make /home/linus/build/gcc> make install
If you are planning to debug your code with GDB, you have to build it as well.
/home/linus> cd build/gdb /home/linus/build/gdb> ../../gdb-6.6/configure --target=sh-elf --prefix=/home/linus/sh1 /home/linus/build/gdb> make /home/linus/build/gdb> make install
NOTE: If you are using GNU/Linux Ubuntu 8.10, you need to add the option "--disable-werror" to configure, like this:
/home/linus/build/gdb> ../../gdb-6.6/configure --target=sh-elf --prefix=/home/linus/sh1 --disable-werror
If you're using a Debian-based distribution, you may run into problems with termcap dependencies (see http://packages.debian.org/stable/oldlibs/termcap-compat).
A workaround for this is to build termcap libs before building GDB:
/home/linus> tar zxvf termcap-1.3.1.tar.gz /home/linus> cd termcap-1.3.1 /home/linus/termcap-1.3.1> ./configure --prefix=/home/linus/sh1 /home/linus/termcap-1.3.1> make /home/linus/termcap-1.3.1> make install
The final step did produce errors as it tried to remove existing header files from /usr/include, so beware, and don't run as root.
Now go ahead and make GDB.
If someone up there likes you, you now have a working tool chain.
Because the versions we use now works. We upgrade when it becomes necessary. Here's a small summary of some other versions we have tried:
r104 - 22 Mar 2013 - 06:57:12 - PatrickRobertsonRevision r104 - 22 Mar 2013 - 06:57 - PatrickRobertson
Revision r103 - 10 May 2012 - 19:24 - PeterDHoye
Copyright © by the contributing authors.