So, I’ve spent the last ten or so hours dealing with GCC build failures, as they’ve cropped up, on the three dev boards.
None of them have yet successfully built a GCC.
MIPS32 is trying to build 4.2.0 and it’s failing because the system GCC has sufficiently different header files to the 4.2.0 code base there’s a missing struct.
Looks like the way to deal with this is to work your way backwards from your current version, through earlier versions of GCC, until you’re compiling with a version so close to the one you want it can compile.
What this means ideally (and I shall do this) is that if your system has say 4.9.2, then you use that to build 4.9.1 and 4.9.3, and then you use those to build 4.9.0 and 4.9.4 – and so on. (Remember GCC builds itself first with the system compiler, then it builds itself again with that compiler, and then it builds itself *again* with that compiler – so we’re only talking here about the system compiler.)
This means though I will now need to figure out now how to build glibc. That was going to have to happen anyway, but it looks like another long, painful – no, *agonizing* – journey of discovery. In the same way that going to the dentist and having tooth removed is a journey of discovery.
So that’s the blocker for MIPS32.
ARM32 is currently trying also to build 4.2.0, and the problem is a missing header file relating to soft floating point. I wonder now actually if this is also a too-large-a-version-gap problem.
ARM64 has a stranger problem. The “aarch64” architecture was introduced in 4.8.0, so that’s the earliest version I can build on this platform. I run into the problem of not finding sys/cdefs.h – but I had this problem on MIPS32 and ARM32, and solved it by setting C_INCLUDE_PATH. That isn’t working now, *even though the required file is under that tree*. Actually I think this might be because it’s trying to compile something to do with C++ (even though it should only be doing C) and I’ve not set CPATH, only C_INCLUDE_PATH. Trying this fix now.