Comment by IntelMiner | Hacker News Reader

Comment by IntelMiner | Hacker News Reader

Parent Full thread

Super niche use case. But I would absolutely love one of these for cross-compiled development work

Right now if I want to cross-compile Gentoo for ARM and ARM64. I can build "most" packages with the included emerge-wrapper. Which is great as it runs basically at 1:1 speed as doing x86_64 compile jobs

However a ton of packages still fail, many of their upstream developers also refuse to incorporate changes that might fix that https://dev.gnupg.org/T2370

For those packages, I have to use a QEMU usermode chroot. Which on my i7-4790 build host, is slower than native compilation on the Raspberry Pi itself

I'd love to be able to do direct, native builds to sidestep these flaws. But every "consumer" ARM board (Raspberry Pi, ODROID, ROCK64 etc) are flawed in some way as to make them unusable for development

- Raspberry Pi lacks enough RAM and will hang even when doing single-threaded builds (heavy packages like GCC and Rust usually hit this limit)

- The ODROID-C2 hits a similar limitation due to only having 2GB of memory itself

- The ROCK64 "can" complete full self-hosting builds (slowly) but has a staggering amount of kernel bugs relating to its Ethernet and USB 3, which frequently cause the system to hang

At work we have a Pi 3b+ build agent and another 3B running a JavaScript-heavy status board. Both had reliability problems (freezing/crashing) until we added heatsinks. YMMV.

I regularly compile big projects like Envoy Proxy, Bazel, CockroachDB, a bunch of Rust tools like ripgrep, bat, fd etc. on my RockPro64 without stability issues. Heatsink is key. I run Ayufan distro as the OS [0]. The additional cores and 4G RAM help with compilation speed a lot over the Rock64.

0. https://github.com/ayufan-rock64/linux-build

> - Raspberry Pi lacks enough RAM and will hang even when doing single-threaded builds (heavy packages like GCC and Rust usually hit this limit)

Can someone ELI5 what exactly the compiler is doing when needs far greater than 2 Gigs of an RPI's RAM to compile itself/Rust?

Also, how is it a "flaw" of the RPI that GCC must exceed 2 Gigs of RAM to compile itself/Rust?

Warning-- I may use the explanation to cudgel future Electron-so-fat threads...

Generally it is the linker that seems to be the issue AFAIK. 32 bit platforms can no longer link at all for large programs like Firefox. Link time optimization will probably make this worse. The gold linker (that Android uses) uses less memory than GNU ld; possibly the llvm linker is better too.

Are there any articles about the algorithm GNU ld uses and why it can't work efficiently with less memory?

I’ve gotten around memory issues by adding a sufficiently large swapfile on raspberry pi

I do native builds of a relatively big C software project on an odroid-xu4 all the time. What are you building that needs more than 2gb for (presumably) linking? LLVM and maybe the kernel comes to mind? just curious

Running a build of Ayufan's 4.19 patches on a rock64 with latest dev device tree from the Armbian project. Eth runs close to theoretical, finally, and I've not observed any issues with USB3 either. Months of uptime, TB of traffic.

Here with the rock64 it was just a matter of time till hardware support settled in mainline, and it seems like we're there!

Reply on news.ycombinator.com