After a bit of hackery I've managed to get BeebAsm 0.06 working under RISC OS. Apart from the errno.h #include and the usual makefile changes I also had to fix a couple of GCC's headers since they seem to be a bit messed up for C++ under RISC OS.

Anyway - RichTW, how do you want to handle the distribution of any and all ports of BeebAsm? Just an extra bit in the downloads section of the wiki page that porters are free to update themselves?

Also are you going to decide on the software license before or after the port(s) are released?

Good work on the port to RISC OS, and cheers also to Jon and Nicola for getting it running on MacOS and Linux respectively! It's nice to see that it's been a relatively painless job to port.

Here's how I think I'll handle this: I'll incorporate the various compatibility fixes back into the source code, and upgrade the version number to 1.00 as the first 'stable' release, now that BeebAsm's had a little time to mature. Then I'll upload a new Windows release, together with source code which should hopefully be compatible with all four platforms.

As far as the license goes, BeebAsm will be released under the GNU GPLv3 License ( http://en.wikipedia.org/wiki/GNU_General_Public_License ).

When I've made the relevant wiki changes, please feel free (everyone) to upload your own platform distributions of BeebAsm! As per the above license, please ensure to distribute the source code in the package

Also, while I'm here, a quick question: what were the nature of the C++ header changes you had to make for RISC OS? Ideally I'd like to make sure that my source code is compliant, rather than having to hack standard headers... even if there's a bug in the RISC OS C++ library set, it's preferable to fix it in the BeebAsm source - after all, BeebAsm already has to work around a bug in the MinGW libraries regarding seeking in text-mode files.

After a bit more poking it looks like the RISC OS header problems can be avoided just by changing the compiler options. Which is good, because for a minute there I was wondering if anyone had actually tested the C++ compiler

The makefile settings I'm using are:

makefile:
TARGET := ../beebasm
WARNFLAGS := -Wall -W -Wcast-qual -Werror -Wcast-align -Wold-style-cast -Woverloaded-virtual -Wno-uninitalized
CXXFLAGS := -O3 -mthrowback $(WARNFLAGS)
LDFLAGS :=
PARAMS := -i ../demo.asm -do ../demo.ssd -boot Code

makefile.inc:
CC := gcc
CXX := gcc
LD := gcc
MKDIR := echo mkdir
RM := echo rm
ECHO := @echo

Removing -Wshadow is a work around for GCC's locale_facets.tcc where __ctype is defined in some inlined code, shadowing the definition in ctype.h
Adding -Wno-uninitialized hides lots of warnings about variables potentially being clobbered by longjump/vfork (neither of which your code seems to use). Most of these warnings come from GCC's fstream and sstream headers.
Removing -pedantic is a work around for unixlib's stdlib.h where inlined versions of atof, atoi and atol aren't marked as throwing exceptions, like their prototypes suggest they should.
The -s is gone from LDFLAGS because (a) all linking on RISC OS is static (untill GCC 4 with ELF support is released), and primarily (b) because specifying '-s' seems to confuse ld and it fails to find any of the libraries.
Also note the use of forward slashes instead of backslashes in PARAMS; unixlib's unix-to-RISC OS path conversion copes with forward slashes, but not backslashes. (You could also swap it for the proper RISC OS ^.demo/asm style path)
And since MKDIR was being fed a unix-style path but cdir only accepts RISC OS-style paths, I've justed swapped that with 'echo mkdir'. Me creating the objects folder manually is probably a lot simpler than hacking the makefile until cdir gets given a suitable path to use. Also 'make clean' won't work since RISC OS's 'remove' won't like the -r option, so I've just set that to 'echo rm'.

If you've got cygwin installed, then have you considered using cygwin's version of GCC instead of MinGW? You can use -mno-cygwin to build against the MinGW libraries instead of the cygwin DLLs. That way you can remove the mingw/cygwin paths from the makefile and make things a bit simpler for porting.

O.K. then I will wait RichTW to release the 1.0 version before building the Linux package.