Currently, I use the binary release of
armv7-unknown-linux-musleabihf. That one works, but we want to link against the dynamic musl. This doesn’t have a very high priority ATM, because it somehow works.
The PowerPC is more problematic. There’s only
powerpc-unknown-linux-gnu, which dynamically links against glibc. That doesn’t work, since we use uclibc on that device (and want to switch to musl in the future). There’s no statically-linked target available for powerpc. Currently, using the toolchain for all other packages and feeding it to
Xargo, pretending to build
powerpc-unknown-linux-gnu against that uclibc works, I assume uclibc has a different ABI, so it needs to compile against its headers and link against that.
My aim was to get to a similar state with the ARM device ‒ build it using the same toolchain and link against the relevant libraries as the rest of the packages. But the experiments have somewhat low priority, once it was proven we can get a working binary (basically, I concentrate on the development and left it to a colleague maintains the packages and the build machinery).
Yes. The whole firmware/distribution (based on OpenWRT) is compiled by something called „buildroot“. That is a bit of a beast ‒ it starts by building its own cross-compiler and all the libraries. Unless I use the same compiler/linker, the compilation either fails or produces something that crashes at runtime. I probably could persuade some kind of system-wide cross-compiler to work, but I don’t really know where to start (despite coding for routers, I have little experience with cross-compiling ‒ most of the time, I just write and test the code on my desktop and then leave it up to the package maintainers to make sure it compiles) and it would likely be more work than just using the already-working tool chain. It also feels more „right“ to use the same as the rest of the compiled system.
That’s what I’ve used eventually. But that’s not really the first place I look for documentation, to be honest.
Currently, I don’t use any custom triple, it was part of the experimentation ‒ but some day I might want to tweak some of the target CPU features (For example, we can’t run debian binaries on that powerPC, because it is missing some common extensions. I don’t know why the rust program runs, if it’s because the produced binary doesn’t rely on them or I haven’t used any feature that’d benefit from them).
That’s good news. I didn’t pay attention to it lately, I just hope this gets available before we get to release O:-).
Anyway, we already decided Rust is in a good enough state to use for these needs as it is, but any improvements will be very welcome anyway. If you are interested in further details, I’ll be happy to share them (after all, what we do here is open source).