I've used buildroot extensively, and an occasional yockto.

My impression in recent years is that these image cross build environments are just not as frequently needed as they were back in the day of their invention.

My most recent embedded linux environments were just embedded archlinux.

No need to cross build an image, just install and run the minimized linux environment right on the target.

Of course, a big part of the need for these cross-tools is that it seems most modern embedded linux developers are running windoze on their development workstations 8-/

▲

xyzzy_plugh 5 hours ago | parent [-]

Are you proposing compiling on the target? For a vast number of embedded systems that is not only impossible (insufficient disk and memory) but also incredibly slow.

At the end of the day you need some cross compilation just for board bring up.

If you're playing with some platform for which this has already been done, then sure, but that's not really the "normal" way of doing embedded.

▲

KingMachiavelli 4 hours ago | parent [-]

Embedded just means ARM 99% of the time and it's cheaper and easier to use native ARM servers (AWS has them cheap) than to make 100% of software cross compile. Some parts of the firmware might need to be cross compiled but those projects are designed to cross compile.

▲

okanat 3 hours ago | parent [-]

Your target build environment often differs significantly from your server environment, so you end up needing a different toolchain and all of the problems that come with cross-compilation anyway. The toolchain and ABI settings that produce small, battery or instruction cache efficient are usually not you want on servers.

	▲	nrdvana 36 minutes ago \| parent [-]
		I'm not familiar with the problems that would cause "target build environment often differs significantly from your server environment". If you have an ARM server, then you should be able to download and run Alpine docker images, and then fetch most system utilities from the Alpine package repo and then compile a kernel and a few other binaries on top of that, then export an image. The main reason to not run Debian is that Debian usually makes lots of compile-time decisions for you, and chooses to maximize the enabled options of the software. Alpine makes the opposite choices for you, creating very minimal feature sets. It's been working well for me, but my use cases is a lot more like a custom in-house DDWRT firmware kind of a thing. If you've experienced additional constraints that make this pattern unworkable, I'd be interested to hear about them.