4 ms·

>native builds This is the complete opposite way, actually. We need cross-compiling that is just as effortless as native compilation. You should be able to b

>native builds This is the complete opposite way, actually. We need cross-compiling that is just as effortless as native compilation. You should be able to build complex software on a powerful computer and perform costly optimization, then run it on a low-powered device.

joezydeco 4mo ago
Yocto and Buildroot will compile, from scratch, an entire gcc crosstool chain with standard library suite and headers to build fast and then deploy to your target. This exists.
- drdexebtjl 4mo ago
  I wouldn’t call either of those effortless, though. I’m thinking of something similar to Zig’s DX for cross-compilation.
  - jdub 4mo ago
    zig makes cross-compiling easy for a single project - but not everything is zig (or supported by zig cc) the various embedded build systems make cross-compiling easy at scale, which means you often don't need to think about it when adding a new package
nrdvana 4mo ago
It was true in 2005, but still? As I described in another post here, a modern strategy is to get a beefy server than can run the same ABI, then start a docker container and assemble a system from Alpine's package repo, then compile a kernel and a few in-house things, then extract a subset of that into an image. No cross-compile, and most of the useful software is in pre-built binary packages with the compile-time options you would have selected anyway. Even if you don't have a beefy server of the same architecture, you can probably run it in qemu instead of docker to the same effect. And even if qemu is slow, you can run a build of the kernel and your in-house stuff in parallel on 64 cores and not really be affected by the qemu slowdown. I'm interested to hear counterexamples, though.
- drdexebtjl 4mo ago
  I don’t have counter examples, but hear me out. What if this hegemony in ISAs is partially because of the high costs of porting software and toolchains? Maybe the next generation of embedded devices will have ISAs that are, say, extremely optimized for real time industrial controllers, but terrible at compiling C++. It seems a little silly to give up on cross-compilation just because _today_ everything runs on ARM. Especially because cross-compilation is not a particularly hard problem, the problem is with decades of tooling assuming the build and target environments are the same.
  - nrdvana 4mo ago
    Well, I'd say cross-compiling is at least a little problematic... if nothing else, it is a hurdle to running automated tests. And cross-compiling still needs to exist for the people building the package repositories. I'm just sort of advocating that if you have limited amounts of time but want to put together a system image to run in an embedded or embedded-adjacent manner, the least pain / most agile solution is by building on top of a popular binary distro and then using native compilation on appropriate hardware inside a chroot or container that resembles the target.
- kryptiskt 4mo ago
  There are no beefy RISC-V servers. There are no beefy 32-bit ARM servers.
  - itomato 4mo ago
    Beowulf time? I had been maintaining a fork of the U of KY BDR with SBCs and Arm devices in mind, might need to revive it for RISC-V.
  - nrdvana 4mo ago
    > There are no beefy 32-bit ARM servers. "Ampere processors natively support both 32 & 64 bit Android applications and require no binary translation for maximum instance density" ... "Run up to 120+ 3D cloud game instances per socket" ... "DRAM: 384GB - 512GB" https://amperecomputing.com/solutions/arm-native https://amperecomputing.com/solutions/arm-native I've not personally tested this, but it very much appears that just like x86, you can use a 64-bit ARM kernel that has 32-bit support enabled to run a 32-bit userspace, likely compatible with docker, or even just in a chroot. Then with 120 cores, "make -j 120"

joezydeco 4mo ago

Yocto and Buildroot will compile, from scratch, an entire gcc crosstool chain with standard library suite and headers to build fast and then deploy to your target. This exists.

drdexebtjl 4mo ago
I wouldn’t call either of those effortless, though. I’m thinking of something similar to Zig’s DX for cross-compilation.
- jdub 4mo ago
  zig makes cross-compiling easy for a single project - but not everything is zig (or supported by zig cc) the various embedded build systems make cross-compiling easy at scale, which means you often don't need to think about it when adding a new package

nrdvana 4mo ago

It was true in 2005, but still? As I described in another post here, a modern strategy is to get a beefy server than can run the same ABI, then start a docker container and assemble a system from Alpine's package repo, then compile a kernel and a few in-house things, then extract a subset of that into an image. No cross-compile, and most of the useful software is in pre-built binary packages with the compile-time options you would have selected anyway. Even if you don't have a beefy server of the same architecture, you can probably run it in qemu instead of docker to the same effect. And even if qemu is slow, you can run a build of the kernel and your in-house stuff in parallel on 64 cores and not really be affected by the qemu slowdown. I'm interested to hear counterexamples, though.

drdexebtjl 4mo ago
I don’t have counter examples, but hear me out. What if this hegemony in ISAs is partially because of the high costs of porting software and toolchains? Maybe the next generation of embedded devices will have ISAs that are, say, extremely optimized for real time industrial controllers, but terrible at compiling C++. It seems a little silly to give up on cross-compilation just because _today_ everything runs on ARM. Especially because cross-compilation is not a particularly hard problem, the problem is with decades of tooling assuming the build and target environments are the same.
- nrdvana 4mo ago
  Well, I'd say cross-compiling is at least a little problematic... if nothing else, it is a hurdle to running automated tests. And cross-compiling still needs to exist for the people building the package repositories. I'm just sort of advocating that if you have limited amounts of time but want to put together a system image to run in an embedded or embedded-adjacent manner, the least pain / most agile solution is by building on top of a popular binary distro and then using native compilation on appropriate hardware inside a chroot or container that resembles the target.
kryptiskt 4mo ago
There are no beefy RISC-V servers. There are no beefy 32-bit ARM servers.
- itomato 4mo ago
  Beowulf time? I had been maintaining a fork of the U of KY BDR with SBCs and Arm devices in mind, might need to revive it for RISC-V.
- nrdvana 4mo ago
  > There are no beefy 32-bit ARM servers. "Ampere processors natively support both 32 & 64 bit Android applications and require no binary translation for maximum instance density" ... "Run up to 120+ 3D cloud game instances per socket" ... "DRAM: 384GB - 512GB" https://amperecomputing.com/solutions/arm-native https://amperecomputing.com/solutions/arm-native I've not personally tested this, but it very much appears that just like x86, you can use a 64-bit ARM kernel that has 32-bit support enabled to run a 32-bit userspace, likely compatible with docker, or even just in a chroot. Then with 120 cores, "make -j 120"