RISC OS Open Support
From RISC OS
This page is in support of tools and functionality used by RISC OS Open sources.
bzip2 is required to access ROOL archives (bunzip2 has decompression as the default action). 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.
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.
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.
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.
All the C in RISC OS is written or modified to work with Norcroft (Acorn C/C++). This is tolerant of a few things that GCC will not accept (say, passing NULL instead of 0), so those will need to be fixed up. Other issues include occasional inline assembler, which will need to be rewritten using the GCC equivalent (and then #ifdefed).
Finally, the source for the RISC OS SharedCLibrary contains many Norcroft C peculiarities and platform-specific references, and does not readily build with GCC. Fortunately, RISC OS GCC contains its own SharedCLibrary headers and stubs, so building programs against it (which is pretty much everything C in the ROOL sources) is not a problem. Then SCL is still a problem, since it is required to generated a ROM, and should it prove too difficult, it could potentially be substituted with Graham Shaw's version.
The RISC OS assembler code is all written using ObjAsm syntax. This ObjAsm syntax is very similar to the syntax used by the assemblers in RealView Development Suite and ARM Compiler toolchain. It is however sufficently different than the syntax of binutils' gas which is used by GCCSDK GCC 4.x RISC OS port as backend assembler.
The GCCSDK GCC 2.x and 3.x RISC OS ports used a different assembler, AsAsm, as backend and this assembler is currently also present in the GCCSDK Gcc 4.x releases. AsAsm syntax is ObjAsm compatible and has even adopted features from RealView Development Suite and ARM Compiler toolchain assemblers which are not present in ObjAsm. Currently AsAsm v2.00 is able to build the IOMD and IYONIX branches of RISC OS 5. This version is however lacking VFP/NEON support so it can't build the OMAP3 branche.
The ROOL RISC OS build system doesn't support AsAsm out of the box so a couple of small changes are needed to use asasm instead of objasm during the build:
- Copy 'asasm' into 'RiscOS.Library.Acorn'
- Rename the original 'objasm' binary in 'RiscOS.Library.Acorn' to 'objasm-org'
- Create an Obey file called 'objasm' in 'RiscOS.Library.Acorn' with content:
Run <Obey$Dir>.asasm -aof %*0
If you want to use ObjAsm again, you can make another Obey file called 'objasm' with content:
Run <Obey$Dir>.objasm-org %*0
and swap the Obey files 'objasm' in 'RiscOS.Library.Acorn'. Or just copy 'objasm-org' over the 'objasm' Obey file.
This is the main historic C library used for RISC OS C apps. This builds without issue.
This is the other main C library used by the RISC OS sources. I have not built this yet, but do not expect issue.
RISC OS search path used for assembler headers is the system variable Hdr$Path and has as value one or more directories all ending with a dot and separated with a comma (the classic RISC OS system variable path notation). The non-RISC OS native version of AsAsm v2.00 supports such search paths using upcased environment variable name with all dollar characters replaced by underscore characters (so, HDR_PATH) and as value one or more directories (Unix filename specification) separated by a column (the classic Unix search path notation).
Platform Configuration Files
These are a mix of RISC OS Obey files and others, so this needs an equivalent under Linux.
Makefiles and Build System
More to come.