wifi-connect
wifi-connect copied to clipboard
balena-os
Support Linux distros like Alpine by providing musl libc linked binaries
I'd love to be able to use this, but not at the cost of switching everything to a Debian build. What modifications are necessary to get this to run on an Alpine build?
We do not provide yet binaries compatible with Alpine. Our downloadable binaries are linked with glibc, where Alpine is based on musl libc. Once we provide a set of binaries linked with musl libc, it should be relatively easy to get it running on Alpine by installing NetworkManager and dnsmasq additionally. I will update this issue once I have a better idea when we possibly are going to support musl libc.
I changed the title a bit to describe a bit better what is needed to properly support Alpine.
In the meantime, I've worked out a Dockerfile.template and start script that work. Feel free to use parts of it for the official version. I haven't actually ran the binary yet, so I haven't run into problems on that front. Do you think building it in an intermediary container would work?
I won't work from a countainer, since there is not a Rust language distribution for Alpine to build the application natively on an ARMv7 device. The only option is to cross-compile from a x86_64 host. For a Rust application without C dependencies that should be relatively straightforward, but we link to libdbus-1 as well. I have not tried that for musl libc based targets, so I am not sure how easy or difficult that would be..
So I've been looking at this as well just now.
On x86 system (Intel NUC), installing cargo and building wifi-connect works fine in an Alpine build container (resin/%%RESIN_MACHINE_NAME%%-alpine-buildpack-deps:latest) and runs in an Alpine runtime afterwards (resin/%%RESIN_MACHINE_NAME%%-alpine-python:slim), although I am also adding (glibc from https://github.com/sgerrand/alpine-pkg-glibc/releases to runtime container).
However for armhf architecture, there isn't a cargo package in Alpine package repositories and it seems that building it under this architecture has the same problems (musl vs. glibc).
I very keen to use this code, but like @legowerewolf, the cost of switching away from Alpine is too great.
Would be great if you could provide Alpine compatible binary...
I could not find either a glibc compatibility layer that can be installed on ARM devices. Otherwise the application could have just run like it is.
The Rust compiler itself is built across the different supported platforms using the crosstool-NG toolchain generator. For example here is the configuration file for ARMv7: https://github.com/rust-lang/rust/blob/master/src/ci/docker/dist-armv7-linux/armv7-linux-gnueabihf.config
The interesting part is that crosstool-NG supports musl libc as can be seen from the config. My current plan is to update our cross-compilation toolchains to use crosstool-NG as well, since the current mix of Debian/Emdebian/Raspberry ones is causing too much trouble. We need to have stable Rust toolchains for other upcoming Rust projects at Resin as well.
In the future Rust itself will include better support for cross-compilation itself and will not require using GCC for linking to C libraries at all, but for the time being crosstool-NG looks most promising. It is quite nice as well and I am biting my fingernails that I have not started with it from the get go :D
We are actually currently working on updating the CI toolchains that build the releases and Alpine will be included among those.
Hopefully we can get it done in a couple of weeks, but there is no concrete target set. Updating the CI toolchains is the top priority for the project as those are needed to restart development with latest Rust version and switching to some new libraries.
Do the CI toolchains changes mean we should now be able to change the base image in our dockerfiles?
