Attempt 5: developing and building remotely on a linux machine with Cross and Ubuntu on the Raspberry PI Trying to use features = in the build configuration (as well as other tweaks suggested in this scenario) didn’t get me much further and it is only many attempts later that I realized that the C languge library on Raspbian OS is really quite old. It took me a while to puzzle out this one. Some `extern` functions couldn' t be found some native libraries may need to be installed or have their path specified rs : 2074 : undefined reference to ` clang_TargetInfo_getPointerWidth ' rs : 2084 : undefined reference to ` clang_TargetInfo_dispose ` clang. It has the same CLI as Cargo which makes it very easy to start using it.įull of hope, I installed it, built the project, deployed the executable and ran straight into the next issue.Ĭlang.
It spins up a container in order to build the crate. Cross is a Rust tool for “Zero setup” cross compilation and “cross testing” of Rust crates. Attempt 4: developing and building remotely on a linux machine with CrossĪfter a bit of searching, I came across Cross (pun not intended). The GLIBC version of Raspbian OS was too old (compared to the one of the linux machine). With this approach, the project did compile… but running the executable on the Raspberry PI failed. In order to continue development on the Mac (well, sort of) I used Jetbrains Gatway which mostly works. I found a thorough article describing the Cargo setup needed in order to get the cross-compilation to work.
Since I have a few linux machines lying around, I decided to use one of these to build the executable and deploying it to the Raspberry PI. Warning: src/rpi_ws281x/mailbox.c:40:10: fatal error: 'sys/sysmacros.h' file not foundĪttempt 3: developing and building remotely on a linux machine with Cargo This approach works fine so long as the project doesn’t use any libraries with bindings to libraries written for linux, such as the rpi_ws281x library: Attempt 2: developing and building directly on MacOS It also requires to synchronize the source files from the development machine to the PI at every change which is a tedious process by itself. This approach is kind of guaranteed to work, but it’s slow. Jump directly to the summary Attempt 1: developing on Mac OS, building on the Raspberry PI Shiny new MacBook Pro complete with scuba-diving sticker from my wifeĪs it turns out, this isn’t as trivial as I thought it would be. Update (): Updated the article to reflect the usage of VSCode remote development instead of JetBrains Gateway Rust development for the Raspberry PI on Apple SiliconĪ few weeks ago I started building a Rust project for the Raspberry PI using my brand new MacBook Pro with an M1 chip (the old MacBook Pro from late 2013 still works but it simply is too slow for the work I’m doing these days).
0 kommentar(er)
