Comments on the bug after deeper investigation - there was an ask to enable MIPS_FPU_EMULATION, and FWIW, as far as I can tell, it already is based on digging into the upstream 18.06 and master on OpenWRT…
Ultimately - if one is cross-compiling code outside of OpenWRT on MIPS - step carefully and understand the behaviors there across different MIPS targets.
–
Had a chance to do some additional investigation on the ask here…
OpenWRT 18.06, and current master has the MIPS_FPU_EMULATOR enabled for both ar71xx and ath79 targets
The proposed 304-mips_disable_fpu.patch is something different - and that patch is in the the git and explains itself - something tells me it is still in discussion and not fully committed.
MIPS and FPU is a bit complicated - general guidance is to keep the emulator on, whether on a target that does have an FPU or not, as the MIPS floating point unit has crashing bugs, and the logic with soft float is smart enough to pass on to the coprocessor the instructions that would benefit at a slight cost.
GCC is strict - so one has to include -msoft-float in the compile directives, otherwise GCC assumes that an actual FPU is present, and it starts emitting assembler code to that effect. The challenge here is that when cross compiling, unless one sets the msoft-float ether in the make file, or in the environment parameters, one is going to get hard float code out of the cross compile toolchain, hence the crashing behavior outside of the OpenWRT environment.
The blame for NodeJS (and NodeRED) is really on the NodeJS team, the upstream V8 engine, and GCC in general - MIPS could take some of the blame here as well, by having a broken hard FPU… OpenWRT and the team that manages the MIPS based platforms could do a better job of explaining the how’s and why’s, as there is much confusion around this issue.
There’s nothing to do here for GL-iNet or the OpenWRT team - it’s really up to the external application devs outside to ensure that their code properly builds.