Chirpstack Gateway OS Yocto build - rust build error

I am attempting to incorporate parts of the chirpstack-gateway-os build into my own Yocto image. I had this working with v3, and I think I have worked out what I need to build everything in v4, except for an error in the cargo-native compile phase. I do not see this problem in the chirpstack-gateway-os build, only in my build. I have reconciled settings and I cannot determine what is different.

Here is the error in my build of cargo-native:

Error loading target specification: Could not find specification for target “x86_64-linux”. Run rustc --print target-list for a list of built-in targets

This is in response to the compile command (leaving out some of the path):

..../work/x86_64-linux/cargo-native/1.66.1-r0/cargo-1.65.0-x86_64-unknown-linux-gnu/bin/cargo build -v --target x86_64-linux --release --manifest-path=..../work/x86_64-linux/cargo-native/1.66.1-r0/rustc-1.66.1-src/src/tools/cargo//Cargo.toml

In the chirpstack-gateway-os version of this step, the command is:

.../work/x86_64-linux/cargo-native/1.66.1-r0/cargo-1.65.0-x86_64-unknown-linux-gnu/bin/cargo build -v --target x86_64-unknown-linux-gnu --release --manifest-path=..../work/x86_64-linux/cargo-native/1.66.1-r0/rustc-1.66.1-src/src/tools/cargo//Cargo.toml

The difference is --target x86_64-linux vs. --target x86_64-unknown-linux-gnu . I do not understand why my build is using x86_64-linux, which is not in the result of the rustc ---print target-list command suggested in the error.

I am building with MACHINE = raspberrypi4-64, but I have successfully built the chirpstack-gateway-os image using that same setting.

I am fairly familiar with Yocto, but not rust or the rust layer. Can anyone point me in the right direction or explain why my image might be using x86_64-linux instead of x86_64-unknown-linux-gnu?



I have been able to get the rust build completed by adding release 1.66.1 to the official meta-rust layer. Pull request here (in the fix-kirkstone branch).

The next issue is with building paho-mqtt-sys during the chirpstack-mqtt-forwarder build, which fails with the error below. I am able to build the forwarder for the target platform aarch64 using the development Docker container, so for now I am removing it from my image build and manually moving it over once the OS is installed.


|   cargo:root=/home/doug/os-build/build/tmp-glibc/work/cortexa72-oe-linux/chirpstack-mqtt-forwarder/4.0.0-r0/build/target/aarch64-oe-linux/release/build/paho-mqtt-sys-83b91adb360f1ce0/out
|   debug:CMake output dir: /home/doug/os-build/build/tmp-glibc/work/cortexa72-oe-linux/chirpstack-mqtt-forwarder/4.0.0-r0/build/target/aarch64-oe-linux/release/build/paho-mqtt-sys-83b91adb360f1ce0/out
|   debug:link Using SSL library
|   debug:Using Paho C library at: /home/doug/os-build/build/tmp-glibc/work/cortexa72-oe-linux/chirpstack-mqtt-forwarder/4.0.0-r0/build/target/aarch64-oe-linux/release/build/paho-mqtt-sys-83b91adb360f1ce0/out/lib [paho-mqtt3as]
|   debug:Using Paho C headers at: /home/doug/os-build/build/tmp-glibc/work/cortexa72-oe-linux/chirpstack-mqtt-forwarder/4.0.0-r0/build/target/aarch64-oe-linux/release/build/paho-mqtt-sys-83b91adb360f1ce0/out/include
|   debug:Using bindgen for Paho C
|   debug:clang version: clang version 14.0.3 ( 1f9140064dfbfb0bbda8e51306ea51080b2f7aac)
|   debug:bindgen include path: -I/home/doug/os-build/build/tmp-glibc/work/cortexa72-oe-linux/chirpstack-mqtt-forwarder/4.
|   --- stderr
|   fatal: not a git repository (or any of the parent directories): .git
|   /usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
|   /usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found, err: true
|   thread 'main' panicked at 'Unable to generate bindings: ()', /home/doug/os-build/build/tmp-glibc/work/cortexa72-oe-linux/chirpstack-mqtt-forwarder/4.0.0-r0/cargo_home/bitbake/paho-mqtt-sys-0.8.0/
|   stack backtrace:
|      0: rust_begin_unwind
|      1: core::panicking::panic_fmt
|      2: core::result::unwrap_failed
|      3: core::result::Result<T,E>::expect
|      4: build_script_build::bindings::place_bindings
|      5: build_script_build::build::main
|      6: build_script_build::main
|      7: core::ops::function::FnOnce::call_once
|   note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Pull request actually here. Turns out the fix-kirkstone branch was obsolete, so I resubmitted the changes against master.

@brocaar Are you interested in moving the gateway OS back to using the meta-rust layer? If yes, I can tackle that.


Are you interested in moving the gateway OS back to using the meta-rust layer? If yes, I can tackle that.

Hi @dreese, please note that Rust has been added to the openembedded-core layer (I believe based on the meta-rust layer), see: OpenEmbedded Layer Index - recipes. The reason I’m overwriting some Rust packages is because I needed a newer compiler version. I basically backported the Rust recipes from a newer Yocto version, that is all. I initially tried using a newever Yocto version, but I ran into a really weird NodeJS issue: NODE RED problem on version 4.0.1 · Issue #95 · chirpstack/chirpstack-gateway-os · GitHub.

The next issue is with building paho-mqtt-sys during the chirpstack-mqtt-forwarder build, which fails with the error below.

It looks like the real error is /usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found. Could it be that you are missing a dependency? I usually use the Debian package index to find to which package a missing file belongs:

Ah, yes – I did see that error but was assuming the missing file was something in the Yocto or recipe side of things. I changed my Dockerfile package install from gcc to gcc-multilib and it works.

The pull request I submitted to meta-rust (not the one in openembedded-core) adds Rust v1.66.1 to Kirkstone. That patch has now been merged into master. I am successfully building Chirpstack rust binaries in my image using the meta-rust layer.

I will likely stay on Kirkstone for a while, as I get tired of chasing Yocto releases.

Thanks for the hint.


I know, it took me quite some time to trace back the NodeJS Bus error issue to the Yocto update. After each update, there is always something that breaks and needs fixing.

Glad you were able to solve the issue :slight_smile:

I am attempting to do the same as @dreese in that I am aiming to incorporate Chirpstack into my own Yocto image. Is there a guide that I could follow to help me do this?

There is no official guide (that I know of) but I created an example basic Raspberry Pi image incorporating the Chirpstack layer last year.

It’s outdated, as there have been Yocto as well as Chirpstack updates that are not part of the image. However, I have used the same concept with the Kirkstone release and the latest version of Chirpstack recipes.

I would like to say I’ll update my example, but time is very short for me these days. Feel free to ask questions, though (probably best to do so in a new thread).


1 Like

Thanks @dreese . I will ask questions on a different thread (if I have any), but that URL doesn’t work for me. Is it possible that this project is “private” on GitHub?

Apologies, @nocker01 – the repo was indeed private. I made it public.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.