If you read the references above in this thread, there is a box native compiler (this community) and a cross-compilation toolset (OEM) available. For almost all situations these will satisfy your needs/wants. You only need to read on if you are insane(?) enough to still want to cross-compile using other tools.
The first question you need to ask yourself is which environment you wish to build. Most new machines are windows but running a linux virtual machine with VirtualBox, QEMU … is relatively simple. The HDR-Fox T2 is a linux machine so you will probably want to do linux specific stuff. Choosing linux means you can try stuff on your host machine (the one with the build chain on) to decouple the linux specific from the target (the one you run the executable binary on) specific part of any problem you encounter. The next choice is which “flavour” to use, which is the subject of lots of discussion elsewhere. My belief is that Ubuntu is better for people who just want to use it, debian is more useful for developers and red hat is for linux fundamentalists.
I chose debian. I wanted to use gcc version 9.2 or greater which is “pencilled in” on debian 11. Lockdown happened so I made more progress than I anticipated, so I prototyped on debian 10.
Debian provides cross tools with a triplex prefix on the standard tool names for the cross versions. The current mipsel-linux-gnu-gcc(g++) version is 8.3.0 which has compiler libraries compiled for a MIPS32 revision 2 processor. However the HDR-Fox T2 has a MIPS32 revision 1 processor so you need to recompile the default compiler libraries (gcc8.3.0compilerlibs.zip). This will still not create an executable that will run because the default glibc invoked by the compiler is also compiled for the wrong processor but, more importantly, needs a much younger kernel.
The next choice you need to make is libc. The choices are ulibc and glibc. Humax chose ulibc for valid reasons so it has to be present on the target. If you want a different libc then you can only build static because it is not possible to replace the ulibc shared library on the target without affecting the normal operation of the box.
The ulibc vs glibc debate rages elsewhere. The ethos of ulibc is to be as thin (as little code between the application and the kernel) as possible. The ethos of glibc is to provide as much functionality as possible, which necessitates it being more bloated than ulibc. If you read the linux kernel man pages you often come across entries like “a user space … was provided in glibc version … which became a kernel call in version …” but the wording is not consistent enough for a definitive goggle search to find them all. I have found no mention of ulibc providing compatibility code (but I am willing to be educated) so I took a closer look at glibc.
The glibc documentation clearly states that each version supports a minimum kernel version and a little digging finds the rationale. I believe this holds true for the 64 bit machine’s kernel ABI but is questionable for a 32 bit machine’s kernel ABI e.g. the HDR-Fox T2, so I decided to experiment with the glibc version pencilled in for debian 11.
The first problem is that purely static glibc builds are no longer supported despite configure still recognising the option even though it is removed from the documentation. The “trick” found on the internet is to do a “vanilla” build (purely to create the includes… in the build folder), remove all the shared objects and libraries, and then perform a second configure with the options that you actually want (Note: if you do a build clean after the second configure subsequent build will fail big time). Once you can do a static build it is then necessary to hack the configure output (BuildFromSource.pdf) to bypass the primary minimum kernel version enforcement mechanism and source changes (HumaxlibcSource.zip) to include the compatibility code I have found and bypass the 2 secondary enforcement mechanisms I have found before producing a version I am happy with (HumaxlibcBinary.zip).
This is still not binary compatible with the other libraries available from debian as libm has a different ABI in the default glibc (I was working towards debian 11) so you need a compatible version (HumaxlibmBinary.zip).
This gets you to the point where you can produce executables that only need standard c(++) functions. There is not much difference in the instruction set between Mips32 version 1 and version 2 but you are still playing Russian roulette with “Illegal instruction” when you include other pre-built libraries. I played “whack a mole” by always producing a link map and then using mipsel-linux-gnu-objdump -d to find the actual instructions in the executable. Document Number: MD00086 "MIPS® Architecture for Programmers Volume II-A: The MIPS32® Instruction Set Manual" "Appendix A: Instruction Bit Encodings" figures identify the instructions that cause grief. These can be searched for in the objdump output that gives you and address. The address can be searched for in the map which gives the archive and the object file within the archive.
If you want to debug on the target and not use “dwarf 4” as an expletive you will also need an up to date gdb (gdb.7z or gdb.zip). My version provides the native and server executables but not the host executable for remote debugging. My experience is that there is no advantage in remote debugging over native debugging via telnet with putty as the telnet client.
Attachment sizes.txt gives the sizes of the archives referenced above together with a link to my OneDrive with read only access where you can find them.
Edited 29th November 2020
I have updated sizes.txt. It now contains links to arm, i686 and m68k binary archives compatible with linux kernel version 2.6.22 produced for the communities that helped me with generic linux information whilst I produced the HDR-Fox T2 (Humax – kernel version 2.6.18) version. In the process of generating the binaries for other architectures I found 2 more areas of compatibility code in older libc versions that have been reinstated in my sources. An updated Humax binary archive has been produced based on these source updates. The <architecture>libcSourceExtras.zip files are the build folders containing the extra files necessary to bypass the secondary minimum kernel version enforcement mechanism(s).
WhackAMole.c.txt is the source for a program that helps automate the activity described as such above.
