Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is it time for a new Embedded Linux build system?

yoebuild.org

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Is it time for a new Embedded Linux build system?

#81

Post by johnea »

xyzzy_plugh wrote: post #9
johnea wrote: post #5

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 o…

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.

I'm talking about cross building an image, and flashing an entire image onto the target. This is the purpose of environments like yocto and buildroot.

My preference is to cross build packages for each application on my workstation, and maintain a local package repository from which individual packages are installed on the target.

I find archlinux extremely useful in this configuration, because even if I'm not building on the target, the same package maintenance and other system commands are identical to my development workstation.

Additionally, archlinux provides a well documented, and fairly simple process for hosting your own local repositories.

Re: Is it time for a new Embedded Linux build system?

#82

Post by t0mpr1c3 »

yjftsjthsd-h wrote: post #10
wasting_time wrote: post #8

I'm surprised to see no mention of Guix. It solves all of these issues, and already has a good story both for cross and native builds on a variety of architectures. Adding new targets is deceptively easy, just copy an existing template and substitute your values. https://codeberg.org/guix/guix/src/branch/master/gnu/system/... https://codeberg.org/guix/guix/src/branch/master/gnu/bootloa...

Does guix have any advantage here over nix?

Guix has some security advantages (grafts for security patches, full source bootstrapping, 100% OSS) and its documentation is generally thought to be superior to Nix.

For me the main downside of Guix is that the maintenance team is very small, which does not seem sustainable.

Re: Is it time for a new Embedded Linux build system?

#83

Post by cbrake »

xyzzy_plugh wrote: post #9
johnea wrote: post #5

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 o…

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.

There are several ways to compile for the target:

1) Cross compile. Yoe build still does this where it makes sense. (Go apps, likely kernel builds in the future) 2) QEMU user mode - 5-20x slow, but fine for some things. 3) Run yoe-build on any ARM machine (AWS, rPI5, Jetson) 4) Farm unit builds out to runners on cloud ARM machines. (future)

The yoe-build architecture allows for this. Choose the container, host architecture, and location that makes the most sense on a unit-by-unit basis.

Caching is also part of the vision, so we never rebuild something twice, unless it changes.

Re: Is it time for a new Embedded Linux build system?

#85

Post by cbrake »

russdill wrote: post #45

Oi, more AI slop. After dealing with things that have external package management and yocto, I understand the pain. But integrating that into yocto is very doable and is a far better path forward. And "I've been experiment with" seems to just mean "I've been vibe coding"

https://yoebuild.org/faq/#is-yoe-created-with-ai

Yes, much of Yoe build is implemented using Claude Code, driven by specs.

Re: Is it time for a new Embedded Linux build system?

#86

Post by cbrake »

ValdikSS wrote: post #73

Wow, no cross-compilation as a feature?! Architecture emulation with qemu-userspace is 5-10x slower than running a native build. The only 'proper' no-friction cross-compilation system I know is Debian/Ubuntu, because it allows to install foreign architecture libraries into your native system, and has all the wrappers for cross-compilation in dpkg-buildpackage. This way you don't have to maintain cross-compiler or too…

Thanks, I was not aware of this - will look into this more.

Re: Is it time for a new Embedded Linux build system?

#87

Post by cbrake »

shevy-java wrote: post #40

> Fast, reasonably priced prototyping (PCB assembly, mechanical 3D printing, etc.). RAM is expensive now. Reasonably priced seems to be counter to that fact. The whole article feels like a promo-tour. > The catch is that nobody handed us the tools to keep the place running. Software such as homebrew exists. Why is the article ignoring this? Not only does it feel like promo, it now feels like propaganda. Homebrew is a…

I wrote the orignal draft, but used Claude to integrate some feedback. In hindsight, this was a mistake, and I will not do that again. Thanks for the frank feedback.

I'm glad Yocto is working for you.

I'm by no means a Yocto expert like many of you, but I've used OpenEmbedded/Yocto since the start, so I'm quite familiar with it. I started the following project, which Khem mostly maintains these days:

https://yoedistro.org/

Re: Is it time for a new Embedded Linux build system?

#88

Post by cbrake »

sollniss wrote: post #35
Palomides wrote: post #24

Earlier quoted context omitted.

I'm not very familiar with nix, how well does it do with cross compiling? is anyone actually using it for yocto sorts of domains?

You can generally remotely build for any supported architecture[1]. The build process will be painfully slow though if you have cache misses. [1] https://search.nixos.org/options?channel=26.05&query=boot.bi...

Is this similar to QEMU user mode emulation?

Re: Is it time for a new Embedded Linux build system?

#89

Post by ValdikSS »

cbrake wrote: post #86
ValdikSS wrote: post #73

Wow, no cross-compilation as a feature?! Architecture emulation with qemu-userspace is 5-10x slower than running a native build. The only 'proper' no-friction cross-compilation system I know is Debian/Ubuntu, because it allows to install foreign architecture libraries into your native system, and has all the wrappers for cross-compilation in dpkg-buildpackage. This way you don't have to maintain cross-compiler or too…

Thanks, I was not aware of this - will look into this more.

It is not exactly well documented, dpkg-buildpackage (debhelper) has cross-compilation wrappers for autoconf, cmake, qmake, meson, ninja, ant, perl/python, maven, gradle, bmake, golang, probably others.

Here'a s quick start for a C++ application compilation with libncurses6 and libtinfo6 dependencies as an example. `apt build-dep` will install armhf library dependencies and native other build dependencies.

    # Adding armhf architecture support to existing system
    dpkg --add-architecture armhf
    apt update
    # Installing cross-compiler for armhf
    apt install crossbuild-essential-armhf

    mkdir nload; cd nload
    apt source nload
    cd nload-0.7.4

    # Download build dependencies for nload package, for armhf
    apt build-dep -aarmhf nload
    apt install libstdc++6:armhf # build-dep misses this one

    # Cross-compiling for armhf, get .deb package for armhf
    dpkg-buildpackage -a armhf -Pcross
That's it. You get nload_0.7.4-2_armhf.deb without the need to compile libtinfo6, libncurses6 armhf first.

Here's all manual process which involves tinkering with your running system, but there are 'proper' compilation tools like sbuild which bootstrap the (container) OS, configure it for cross-compiling, and do all the required steps from a clear start, with just a `sbuild --host=armhf` call more or less.

Re: Is it time for a new Embedded Linux build system?

#90

Post by nickthenerd »

cbrake wrote: post #83
xyzzy_plugh wrote: post #9

Earlier quoted context omitted.

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.

There are several ways to compile for the target: 1) Cross compile. Yoe build still does this where it makes sense. (Go apps, likely kernel builds in the future) 2) QEMU user mode - 5-20x slow, but fine for some things. 3) Run yoe-build on any ARM machine (AWS, rPI5, Jetson) 4) Farm unit builds out to runners on cloud ARM machines. (future) The yoe-build architecture allows for this. Choose the container, host archit…

Doing this on target seems terrible. What an awful development experience.
Post reply on HN