Revision as of 12:51, 30 December 2007 by Adamr (Talk | contribs)
Jump to: navigation, search


Using GCCSDK to cross-compile for RISC OS

Building the cross-compiler

Cross-compiling for RISC OS is done by using GCCSDK on Unix-alike host system, such as GNU/Linux, FreeBSD, Solaris, MacOS X or even Windows (under Cygwin). To get started, ensure you have a Subversion client installed for your system, and fetch the GCCSDK source to the current directory (which needs about 280MB disc space).

First we set the GCCSDK_SRC variable so this tutorial can refer to the position of the sources (assuming Bash shell is used):

export GCCSDK_SRC=$PWD/gccsdk

Then fetch GCCSDK:

svn co svn:// $GCCSDK_SRC/gcc

Detailed build instructions are given in the file gccsdk/gcc/README (or the WebSVN copy), however they are essentially as follows. Refer to the README where assumptions are noted.

You'll need at least the following programs (or later versions) installed on your Unix-alike machine:

gcc		version 3 recommended
svn (subversion)
bash		for this example
autoconf 	version 2.50
bison		version 1.27
flex		version 2.5.4
gperf		version 2.7.2
sed		version 2.05
GNU make	version 3.80
makeinfo	version 4.2 (see README for Debian notes)

We also need to be able to write to a directory named /home/riscos (this can be changed, see the README).

To build GCCSDK (this may take many minutes, depending on the speed of your computer):

 cd $GCCSDK_SRC/gcc
 autoconf ; autoheader
 make setup
 make build-cross
 make porting-scripts

You now have a complete GCC cross-compiler environment.

Using the cross-compiler on its own

The cross-compiler gets installed in the 'prefix' bin sub-directory given as parameter to the 'configure' script (see 'do-configure' file). You can find the following binaries : ar, c++, cc, cmunge, decaof, drlink, g++, g77, gcc, gcov, libfile, nm, ranlib, resgen, strip and zip, which you can on your Unix-alike host to build RISC OS programs.

Since GCCSDK GCC 3.4.6 Release 3 and with the aid of syslogd module you have RISC OS throwback support in the cross-compiler allowing to have warning and error feedback on RISC OS of compilations done on a remote host.

An example of a more advance use of the cross-compiler is to build GCC for RISC OS (the first 4 steps are not necessary when you already have the GCC cross-compiler built):

 cd $GCCSDK_SRC/gcc
 autoconf ; autoheader
 make setup

Using the cross-compiler and porting-scripts

The porting-scripts are installed in the 'with-riscos-env' directory given as parameter to the 'configure' script (see 'do-configure' file - by default it's /home/riscos/env). The "ro-" prefixed scripts are wrappers around the similar named and well-known build tools to ensure that the cross-compiler is used instead of the native compiler on your Unix-alike host.

So you use '/home/riscos/env/ro-make' instead of 'make' and your project will be built using the cross-compiler instead of the native compiler. You use '/home/riscos/env/ro-config' instead of './configure' and your project will be 'configured' using the cross-compiler settings. And so on.

Using the cross-compiler with Autobuilder

The Autobuilder infrastructure is meant to be able to cross-compile a broad set of open-source programs with a minimal of manual work (ideally none) allowing to have constant access to recent versions of those programs under RISC OS. It consists of a couple of scripts in the Autobuiler directory gccsdk/autobuilder which fetches the to-be-built programs as source from internet and cross-compiles it using the GCCSDK cross-compiler and its porting-scripts.

The recipe to build these open-source programs is stored in a per program unique subdirectory of the 'autobuilder' directory and is holding one or more files specifying where the source can be found, the patches needing to be applied (if any) and how it needs to be built using the cross-compiler and porting-scripts. And finally how it should be packaged and published (either locally in a directory, either uploaded to a website such as Unix Porting Project download pages.

Autobuilder requirements

To install the Autobuilder code itself and a large set of projects which can be built using the Autobuilder:

svn co svn:// $GCCSDK_SRC/autobuilder

The Autobuilder contains a number of programs with quite complex build systems, and has some additional requirements itself which need to be present on the build system. They are the following:


These are the names of Debian's packages for them, other distributions may vary (for example, see the Cygwin page). We strongly recommend to have these packages installed before using Autobuilder as the absence and the problems caused by it could cause some lost time by having to figure out what's going on.

The availability of some of these programs is checked by the Autobuilder.

Source code

Fetching the source code of the open-source programs can be done via different methods like apt-get, ftp, http, svn, cvs, etc. Because of conveniance reasons we try to do that by preference via Debian's 'apt-get' command and specifying their 'unstable' packages (which despite the name usually means stable and up-to-date upstream releases).

To specify which mirror you can use in your /etc/apt/sources.list file, have a look at Debian worldwide mirror sites list. For the UK this is probably something like:

deb-src unstable main non-free contrib

When you do regular builds using Autobuilder you can make use of apt-proxy which caches the fetched sources from the Debian mirrors saving on time and bandwidth.

Simple Autobuilder example

Now use the Autobuilder to build a package:

mkdir ~/build
cd ~/build
$GCCSDK_SRC/autobuilder/build -v wget

This will attempt to build in the ~/build/wget directory (that is, in build/wget in your home directory). If the build is successful this will be deleted and the results placed in $GCCSDK_SRC/autobuilder/autobuilder_packages. This is a Zip file which can be copied to RISC OS to be unpacked and run. If not successful the ~/build/wget directory will remain for you to inspect. The output from the build process is also saved in $GCCSDK_SRC/autobuilder/network/wget as either a file last-success or last-failure depending on what happened.

The cross-build process is controlled by files in the $GCCSDK_SRC/autobuilder/network/wget directory, mostly the 'setvars' file which is executed by $GCCSDK_SRC/autobuilder/build via fetch-program and build-program - look at these three scripts to see what's going on. Sources are fetched automatically from the Debian project's source repository unless otherwise stated, then local patches (if any) are applied before configuring and building.

Porting a new package involves creating a new directory in a suitable place in $GCCSDK_SRC/autobuilder tree and producing a setvars file. You may provide patch files in that directory with names ending in .p will be automatically applied. Look at some of other packages' directories for examples. If you can't find the directory for the package 'foo' you want, try:

find $GCCSDK_SRC/autobuilder -name foo

See Autobuilder documentation gccsdk/autobuilder/AutoBuilder.html (or see HTML source from WebSVN) for more detailed instructions.

A more complex Autobuilder example

There are many more packages and libraries in the Autobuilder, too many to list here. Many of the programs in the Unix Porting Project are represented here. Many of these contain dependencies, which means they will instruct other packages to be built first before they can be built.

The method for building them is precisely the same. For example:

$GCCSDK_SRC/autobuilder/build -v firefox

This will build a version of Mozilla Firefox for RISC OS (see its 'setvars' file to know which version is selected). Note that this has many dependencies and could take some hours depending upon your hardware and network connection.

If you want to retain the source to a package (e.g. for debugging or development), simply use the -d flag alongside the -v flag.


Most problems with using the Autobuilder come from one of three sources:

  • Missing packages on your build Unix system
  • Out of date installation of GCCSDK/autobuilder
  • Upstream changes

If you have an error about missing files when trying to build something, it's most likely that there's something missing from your build Unix system. Try searching your distribution to find out which package these files are installed in: try the 'search within packages' for Debian if you use those, or a similar facility for your build OS.

If you think you've got all the files (ask the GCCSDK list if you aren't sure), it's worth a try to rename /home/riscos to something else and run through these instructions from scratch: this will grab the latest compilers and libraries.

If neither of those have any luck, there have probably been upstream changes. Ideally it's best to fix the Autobuilder and/or libraries so the newer upstream will build, but otherwise you can look at the 'setvars' file and tweak it so it fetches older sources (from a specific tarball, instead of CVS, for example). Look at a few 'setvars' files to see how this syntax works.

If you still have trouble, ask the GCCSDK mailing list. Also if you manage to get anything to build, or spot things which have broken, do inform the list or submit patches.

Using ChoX11 with the Autobuilder

Any program in the Autobuilder which has dependencies upon the X libraries will also require ChoX11 and DeskLib (which ChoX11 uses) to be built. The Autobuilder will instruct the linker to automatically replace library references to the X11 library with ChoX11 and DeskLib.

Help wanted

We want to come to a situation where all the projects defined in the Autobuilder can be built from start to end with a single command and this on all times, and where the resulting packages are uploaded to a single spot at We strongly believe that once this state is reached, only a minimal of effort is needed to keep those projects from then on buildable and up-to-date and that bug fixes in libraries immediately benefit all projects using these libraries.

What are we currently missing for this ?

  • We are in a desparate need of some volunteers to make use of the Autobuilder in order to keep all the projects already defined in Autobuilder up-to-date.
  • Building a large set of Autobuiler projects requires sometimes that a certain project build order is respected. Currently this is done via the 'depends' file. However this is a quite error-prone method and certainly not bulletproof. Usually this 'depends' file gets updated because someone runs into a dependancy problem and fixes that. A possible replacement would be to derive the dependancy from the Debian APT database. More thought is needed on this but for sure it could be improved. It's a nice project on its own. Such a thing is vital if we want to build all Autobuilder projects from start to end.
    Such an improvement would have a major advantage if it would easily allow parallel builds as these days most host hardware have more than one cpu or core and it would be a shame not being able to use them all.
  • Currently the built packages are not yet uploaded somewhere. Alan Buckley made a very nice start to automatically create a webpage pointing to those built packages but we're not there yet. His latest report can found here.
  • Currently packages are zip files. Ideally we want to package them using The RISC OS Packaging Project so that users can easily install them and keep their versions up-to-date (that's why we want to have all Autobuilder projects buildable at all times).
  • For most projects inside the Autobuilder it should not matter if you build them using the GCCSDK 3.4.6 cross-compiler or with the experimental GCCSDK 4 cross-compiler which is currently in development. For those projects were it matters, it would be nice to have them buildable for both cross-compilers for at least the transition period until we have a first stable GCCSDK 4 release.
  • Of course we can always use more projects defined in Autobuilder. The cross-compile build infrastructure is there, it simply waits for you to port your favourate program to RISC OS. Certainly not wishing to limit your ideas but these are particular interesting because they are a missing technologies or libraries or simply too nice not to try them out:
    • It would be great to have a port of Mesa and particular IyonixMesa in Autobuilder as it would all kind of OpenGL based programs to be ported.
    • Flash support: either Gnash (talk to John-Mark Bell as he already did some work), either Swfdec.
    • Gnumeric : well known open-source spreadsheet.
    • Pidgin : previously known as GAIM is a GTK+ instant messaging application. It supports multiple protocols, including AIM, ICQ, Yahoo!, MSN, Jabber, IRC, Napster, Gadu-Gadu, Zephyr, and SILC.

Discussions, questions, new ideas or just a statement you're want to help here can be done in GCCSDK mailing list.


  • An excellent tutorial on GNU Autotools can help you understanding how most packages are configured using the GNU Autotools and built in Autobuilder.
  • The Goat Book (GNU Autoconf, Automake and Libtool)
GCC and GCCSDK pages

GCC for RISC OS, GCC tutorial, GCC common switches, GCC for beginners, UnixLib, ELFLoader
GCCSDK and Unix porting
GCCSDK, GCCSDK Releases, GCCSDK Development, Using GCCSDK, Autobuilder Development and Packaging Cygwin setup, Accelerating autobuilder with apt-proxy, ChoX11, Developer help wanted

Personal tools