Revision as of 16:00, 2 February 2008 by Pnaulls (Talk | contribs)
Jump to: navigation, search


Using GCCSDK to cross-compile for RISC OS

Building the cross-compiler

The previous version of these instructions referred to the use of the GCC 3.4.6 cross compiler. Due to ongoing development, this may no longer work with all autobuilder packages. The focus is now on the GCC 4.1.1 cross compiler with the autobuilder.

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).

Fetch the compiler and autobuilder:

svn co svn:// gccsdk

Build the cross compiler and follow the prompts:

cd gcc4

This will ask you to confirm the settings in the created file 'gccsdk-params'. More detailed help can be found in the README in this directory. It may ask you to install additional tools. The full list is as follows:

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)

Then run build-world again:


Expect this to take many minutes, or even longer. If this all went ok, then the cross compiler is built ok, and you can proceed to use of the autobuilder. If not, consult the README for what to do next.

Autobuilder requirements

The Autobuilder will have already been checked out in the above instructions and lives in the directory gccsdk/autobuilder. You should not try to build from with that directory. Under the gccsdk directory, create an additional directory 'build'. You will then have these directories:

autobuilder (Autobuilder files)
build (Build work directory)
gcc4 (Cross compiler source)

Possibly also, if you made the install targets for example ~/gccsdk/cross/bin, and ~/gccsdk/env, but might otherwise be in /home/riscos/cross/bin and /home/riscos/env



cd .. (from gcc4 directory)
mkdir build
cd build

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 these programs is checked as needed by the Autobuilder, and they aren't all required for simple builds.

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 convenience 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:

../autobuilder/build -v wget

This will attempt to build in you 'build' directory the wget package. For any package, the Autobuilder will need to first try and build and dependencies. In this case, there's a few - it needs to first build a special RISC OS specific version of 'zip' to run on the cross compiling system which understands RISC OS filetype conventions under Unix in order to usefully package the result. The wget package also relies upon the zlib library (zlib1g) and the OpenSSL library (libssl0.9.8), so these will be built too.

The work is done under a created 'wget' subdirectory. If the build is successful this will be deleted and the results placed in ../autobuilder/autobuilder_packages. This is a zip file which can be copied to RISC OS to be unpacked and run (It's actually a RiscPkg package). If not successful the wget directory will remain for you to inspect. The output from the build process is also saved in ../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 ../autobuilder/network/wget directory, mostly the 'setvars' file which is executed by ../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 ../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 ../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. Most 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:

.../autobuilder/build -v firefox2 -D

This will build a version of Mozilla Firefox 2 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 as in the example here.


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 desperate 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 dependency problem and fixes that. A possible replacement would be to derive the dependency 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 favourite 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