Meeting: What has Cross-Compilation ever done for us?

Report by Peter Richmond and Steve Fryatt

The March talk was hosted by Steve Fryatt from our Club, and was about cross compiling and how it helps the RISC OS community. Steve was explaining this with the use of the Club RiscPC and his own laptop running Linux.

Cross compilation

Steve first looked at writing a simple BASIC program on the RiscPC, and then showed how he would write the equivalent program in C using the original Acorn ‘Norcroft’ compiler (as taken on by Castle and now maintained and sold by RISC OS Open Ltd – the name, incidentally, came from two of its original authors: Arthur Norman and Alan Mycroft).

While Norcroft C was – and still is – good, Acorn’s Desktop Development Environment which came with it used several non-standard support tools, and this could often make it difficult to work with code written for compilers on other platforms. Since the mid-90s, Norcroft has had ‘competition’ from the RISC OS port of the GNU C Compiler, or GCC: this is the defacto standard compiler on the Linux platform, and much open source software has been set up to work with it.

With this in mind, Steve then took the simple C program and compiled it again on the RiscPC – this time using our native port of GCC. The process was less drag-and-drop than with Norcroft, and it required the typing of a command on the command-line, but the end result was the same: a file which, when double-clicked displayed the text “Hello World” on the screen.

Next, Steve copied the source code for the simple program across to the laptop and entered the equivalent command under Linux. Again, GCC compiled the code, but this time in a form that would run natively on the laptop. This wasn’t too surprising: the copy of GCC installed on Linux was set to create programs that would run on Linux!

So, for the final stage of the circular process, Steve entered another command on the Linux command line which invoked something called the ‘GCC Cross Compiler’. This is a version of the RISC OS port of GCC, but built so that it will run on Linux and not natively on RISC OS. The file that came from this would not run on the Linux laptop, but when copied back to the RiscPC it ran perfectly and once more greeted us with “Hello World”.

So what?

So how does this help the RISC OS community?

The most immediate benefit is speed: GCC on x86 hardware is much faster than GCC or Norcroft on even an XScale-based ARM system. To give one extreme example, NetSurf – which Steve has found the need to compile a few times recently – takes many minutes to build on an Iyonix while compiling in only a few tens of seconds on a modern Linux desktop system.

Even if developers are happy to go and make a cup of tea while the compiler does its stuff, there are other good reasons why we might want to build our RISC OS software in a Linux environment. The compiler itself is only one of many tools used to put together a modern piece of software, and sadly many of the others are simply not available on RISC OS.

This may not be a problem for native software, but if we’re interested in making use of code written by developers on other platforms it can be a great help. At this point, Steve showed us a jigsaw puzzle game called XJig, running natively on the RiscPC. However, it originated on Unix systems and Steve then switched across to the laptop and showed the same game running on the Linux desktop.

Automatic software

XJig is one example of a number of pieces of software that come to us via something called the ‘Autobuilder’. It’s a tool that lives out on the internet: developed and maintained by the same team who look after the RISC OS version of GCC and the GCC Cross Compiler. The basic premise is that a RISC OS developer can point the Autobuilder at the source code for a piece of software developed for Linux, and out will pop a version of the software that will run natively on RISC OS.

Of course it’s not quite that simple, however the aim of the system is to use the Linux-based build scripts that come with the software we’re interested in but to ‘trick’ them into using the Cross Compiler and any RISC OS-specific libraries that are required. This has the benefit that in some cases, updates made by the original authors – for Linux, and with no knowledge of RISC OS – will simply pass straight through the Autobuilder and fall out on our RISC OS side with little or no extra effort on our part.

While XJig is a striking example, it has to be said that the Autobuilder works best for things that don’t have the complexities of a graphical front-end. A look through the Autobuilder package listing on riscos.info reveals many command line tools (such as WGet, which can be used to fetch webpages from Obey files) and libraries which go on to form building blocks of other software.

Other people’s wheels

Open-source libraries sourced in this way now form part of a number of native RISC OS applications: saving our developers from having to re-invent already well-developed wheels. NetSurf relies heavily on libraries that can be built in the Autobuilder for things like image decoding; PDF uses them to render ‘Acrobat files’. The porting of software like Ghostscript (as used for PDF generation by packages such as PDFMaker, PrintPDF and the EasiWriter family) has been simplified with these tools, and there are many more examples besides.

Sometimes the software that we get will be fully compliant with the RISC OS ‘look and feel’ (NetSurf and PDF both pride themselves on their Style Guide compliance), and sometimes it won’t (for example XJig or Firefox). Either way, the availability of modern programming tools and the way that the Linux community works (the software being open source) mean that we can benefit from the work done by programmers working for Linux.

Given the number of active RISC OS software developers, this can only be a good thing!