Well, I'm not sure if it's a bug or what (when gcc crashes, it says to report it as a bug), but I was trying to compile Monero on an Orange Pi PC2 (yeah, pointless, I know, but just for the PoC) and the memory (and lack of swap) came up. Here's my config:
root@orangepipc2:~/monero# uname -a
Linux orangepipc2 4.14.7-sunxi64 #38 SMP Mon Dec 18 00:49:34 CET 2017 aarch64 aarch64 aarch64 GNU/Linux
root@orangepipc2:~/monero# cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD_NAME="Orange Pi PC2"
Swapiness is configured as follows (looks good to me):
root@orangepipc2:~/monero# sysctl -A 2>&1 | grep swap
vm.swappiness = 60
and my zram is configured as follows:
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 124.3M 124.2M 5
/dev/zram1 partition 124.3M 124.2M 5
/dev/zram2 partition 124.3M 124.2M 5
/dev/zram3 partition 124.3M 124.2M 5
Ready to compile!... Huh? No.
Running make (even "make -j1"!), the thing froze every time and took ages before I could ssh again (I'm not fond of unplugging it and the power-off button seems software-controlled, just like the LEDs, not a NMI, just as frozen as the OPiPC2 itself). It's so frozen that there's "no route to host" when I try to ssh or ping it (I keep it headless, there's nothing plugged on the USBs).
The nohup.out shows that, within seconds, the situation comes to a point where cc1 is killed. Pretty ungood, isn't it?
Initially, I thought it was CPU over-usage, but htop showed me it actually was the memory getting completely filled, and then the swap (but is it swap or zram in that case? there's no swap configured...).
So, yeah, I know, it's not clean to configure swap on a SDCard, but:
fallocate /var/swap.file --length 8GB ;
chmod 0600 /var/swap.file ;
mkswap /var/swap.file ;
swapon /var/swap.file ;
nohup make -j3 &
Initially, I tried just 1GB, bringing total swap to 1.42GB, but htop showed it was eaten up in a matter of a couple of minutes, so I went directly to 8GB. At the moment, load average is at 4.17, swap is 2.15G of 7.94G (well beyond anything I could get without configuring a swap). It's not very reactive (to say the least), but it's working.
So, unless there's a way to tell make/cmake//gcc to do otherwise, or a "cleaner" way to get the same result, adding a big swap on the SDCard was the only way to get things done... Slowly, wrongly, but done.