Using GCCSDK

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, using GCC 3.4.6 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 a 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://svn.riscos.info/gccsdk/trunk gccsdk

Build the cross compiler and follow the prompts:

cd gccsdk/gcc4
./build-world

This will ask you to confirm the settings in the created file gccsdk-params. More detailed help can be found in the README file in the gcc4 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
• autoheader
• 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:

./build-world

Depending on your hardware, this may take a long time to complete. If this all went ok, then the cross compiler has been built successfully, and you can proceed to use 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 within that directory. Under the gccsdk directory, create an additional directory 'build'.

cd ../
mkdir build

You will then have these directories in the gccsdk directory:

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

(Note that the build process will have also created the directories /home/riscos/cross/bin and /home/riscos/env, unless you changed the defaults.)

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:

• autoconf
• automake
• cvs
• doxygen
• dpkg-source
• gettext (for xgettext)
• libglib1.2-dev
• liborbit-dev
• libpopt-dev
• pkg-config
• realpath
• rman
• svn
• unzip
• wget

These are the names of Debian's packages for them, other distributions may vary (for example, see the Cygwin page). We strongly recommend that these packages are installed before using Autobuilder, as their absence can lead to wasted time trying to identify the potential resulting problems.

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 http://ftp.uk.debian.org/debian/ 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:

cd build
../autobuilder/build -v wget

This will attempt to build the wget package in your build directory. For any package, the Autobuilder will first try to build the package's dependencies. In this case, there are a few. For instance, 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 in build 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.

Troubleshooting

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 ensure te latest latest compilers and libraries are used.

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 on 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 riscos.info. 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 4.1.1. However updates and improvements are now being concentrated on the 4.1.1 cross-compile environment, so that should be used in preference to 3.4.6.
• 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.

Links

• 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 under RISC OS 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