Hi all. I'm new to this forum and to RISC OS, but I've been having a lot of fun with it over the past few weeks. I've been looking for a simpler, more user-friendly OS to play with than Linux, and RISC OS has so far exceeded my expectations, including with GCC and UNIX source code compatibility.
Stefan noticed my Twitter posts on the topic and invited me to post here, since I've been looking at GCC 10.2 in autobuilder. I have noticed a few issues that I wanted to share. First, if I try to upgrade the port to GCC 10.3.0, the build fails trying to build libatomic, which doesn't happen with 10.2.0. If I try to upgrade from binutils 2.30 to binutils 2.31, then the linker joins the code and data segments together and the soloader fails with a missing data segment, due to a RISC OS patch that I don't know yet how to apply properly to 2.31. I made much more progress staying with GCC 10.2.0 and binutils 2.30, but it should be possible to upgrade to the newer versions by updating the patches to handle these failures.
The next issue I had was figuring out how to run "make ronative", "./create-gcckit", and "./create-riscpkg" in the gcc4 folder to create updated ARMEABISupport, DRenderer, SharedLibs, and SharedUnixLibrary packages to replace the ones I downloaded from PackMan. Without doing this, "coreutils" programs would crash with random jumps to 0x22xxxxxx (I didn't write down the addresses), and then every GCC 10 program would crash the same way until I rebooted, but after replacing those shared packages, the only instability I'm seeing now is that bash will often silently exit, or give a NULL pointer exception, immediately after running "ls" or some other command. But when I use the dash shell instead of bash, it works perfectly.
I've had to make quite a few patches to get things working, so I need to figure out who to coordinate with about submitting my patches and hopefully new ports. I'd like to port xscreensaver, to learn about the Wimp APIs, using its cross-platform Xlib emulation (which currently supports Android and Cocoa) with OSLib, and because it'll look cool. I just found out about ChoX11, but I'm not convinced that it's the most optimal solution for xscreensaver, since it depends on DeskLib, which doesn't seem popular compared to OSLib, and I'm also assuming xscreensaver's Xlib emulation is more optimized for its needs. Also, I want to know what's going on natively to make sure it works as a RISC OS screensaver (I found an archived tutorial on how to do that).
I was happy to get Qt5 built, but when I try to run RPCEmu, it complains that it can't find the "riscos" module, so I need to investigate that. These are all using GCC 10.2.0, not 4.7.4. I'm also working on getting SDL 1.2 running, which seems to be looking for X11 instead of any native RISC OS code that it should be using. If I can get Qt5 and SDL 1.2 running using the new compiler, that will unlock almost all the ports I'm interested in using.
One last detail that made me happy: Trying to build SDL 2 brought in "Khronos" as a dependency, a port of the Raspberry Pi userland to talk to the VPU for GL ES 2.0 and video decoding. I had low expectations that I'd be able to draw a 3D triangle in RISC OS with hardware acceleration, but I actually got it working, or at least the Wimp demo (the other three demo apps immediately fail with a stack trace that's not helpful, and I'm not why that is). But the bad news is I had to use GCC 4.7.4 to build the Khronos modules and also the shared libs and sample programs.
If I try to build the Khronos VideoCore libs using the new compiler, the first problem I run into is the module won't link. The new compiler seems to recognize "-mmodule", but I can't get it to link because it's trying to pull in the wrong FP libraries (FPA instead of VFP) and getting mismatches between the two formats. I'm not sure if this is being worked on. And then if I build the module with GCC 4.7.4 and the shared libs and demo app with GCC 10.2.0, the system is unreliable and freezes (instead of just not starting the app), presumably a combination of incompatible FP formats and the OS module not properly validating its inputs.
The only other issue I wanted to note here is the current GCC 10.2.0 build is building "SharedLibs-C-armeabihf", "SharedLibs-C++-armeabihf", and "SharedLibs-Fortran-armeabihf", instead of the GCC 8 port's "SharedLibs-armeabihf", or the "SharedLibs", "SharedLibs-C2", and "SharedLibs-C++2" packages of GCC 4.7.4. It looks like there are package filename conflicts between GCC 8 and GCC 10, but not between either of those and the GCC 4.7.4 packages, but the current "setvars" for GCC 10 isn't correct since it's making a package depending on "SharedLibs-armeabihf" while creating the three packages I mentioned. I'm assuming the intent is to migrate to depending on the C and C++ (if needed) shared libraries explicitly, including for the GCC 10 port itself, but that hasn't been done.
One note about distributing binaries built with these compilers: by default, the code will require VFPv3 and ARMv7-A, which means programs won't run on the original Raspberry Pi or other ARM11 / ARMv6 CPUs, but should run on anything newer. I don't see anything enabling NEON support by default, but if you do that, you'll further restrict supported CPUs. These are set with the "--with-abi=aapcs-linux --with-float=hard --with-fpu=vfpv3 --with-arch=armv7-a" flags to GCC's configure script.
Are there a lot of people who care about ARM11 or older? If so, then any future package archives will need to have an "armv6" directory as well as "armv7". If further optimization is needed, you could specify "-mcpu=" with the specific CPU type, which may be especially helpful for the Cortex-A72 and similar out-of-order CPUs. It'll also be necessary to compile libgcc, libstdc++, and the other GCC shared and static libraries for older ARMs than ARMv7-A.
I'll add more notes as I discover things, but I wanted to share that the new GCC is definitely working fairly well for me, after a lot of effort spent on patching the build scripts (I'm running it on Ubuntu on x64, since the scripts don't run on macOS due to using GNU command-line options macOS doesn't support). Thanks to everyone involved in the porting effort. I hope to contribute my own patches in the near future. Very exciting times for RISC OS!
Jake Hamby
RISC OS Developer Forum - Open Source for ARM SoC #Raspberry Pi #Acorn
