RISC OS Open Support
This page is in support of tools and functionality used by RISC OS Open sources.
bzip2
bzip2 is required to access ROOL archives. This can found here:
Building ROOL Sources with GCC
I have been looking at the problem of compiling the RISC OS sources from ROOL using GCC. There are a number of distinct problems to be solved. This documents the issues.
Aim
Allow build of all, or at least, significant parts of the RISC OS sources sufficient to build a minimal ROM, or to allow improvement of the core RISC OS apps (Paint, Draw, etc). For the ROM target, a reasonable choice is the IOMD build (RiscPC/A7000), since I can easily test this under RPCEmu. The goal here is to build using the GCCSDK cross compiler on Linux, but also at least be able to build some of the components natively under RISC OS using GCC. It is imperative that the source continues to be build using the native Acorn C/C++ suite.
Filenames
CVS Names
The C files in the ROOL CVS are in RISC OS format, which is an issue when trying cross compile. That is, c.progname (where c is a directory name), rather than the Unix format progname.c. In many cases, using CVS or Subversion under RISC OS will deal directly with Unix format names, and convert locally to RISC OS format (which is why this isn't generally an issue). But it's not really convenient to a source-wide rename. It would be possible to modify the GCC cross compiler to understand these names, but it still causes problems for 'make' and precludes use of other tools later on (e.g. lint).
The solution I have taken is instead to have a script that creates a symlink of the sources into the canonical names. This script do other things such as linking "Makefile.GCC" to just "Makefile" in the symlinked directory. It also allows separation of native build objects from the cross ones.
Includes
Many C #includes refer to "h.filename", rather than "filename.h". Again, GCC could probably be patched to understand this, but it's better to simply fix them up. In my local sources I have done this in an automated fashion, and have several hundred pending changes to CVS.
There are some wackier names, like "h.dirname.filename", which really require some manual path changes in CVS. This only occurs in a few places, but I have pending changes for these also.
Finally, because of the case-insensitivity of the RISC OS filename handling, in many instances, the #include names do not match in case. This is generally a manual fix as I go along.
Some of these same issues apply to assembler, such as reversing s.filename in GET statements.
