musl support (prefer musl for linux?)

[Gankra]

Prebuilt binaries for linux are a mess for various reasons (e.g. #73), and preferring musl over glibc fixes some of those issues (in exchange for other subtle problems that I'm assured are minor in comparison).

This requires some basic cross-compilation support to get the toolchain from rustup and to use musl-tools (#74).

[frol]

In my experience, it is not always straightforward to get binary compiled against musl and/or static build. Just to name a few showstoppers:

• the features that require udev and dbus usually need to be feature-flagged and disabled in musl context
• openssl is another common problem for static linking

Thus, when we can automate things and create dedicated packages for all the platforms separately, that is still the best way, unfortunately.

P.S. Thanks for starting this project! I was dreaming of it for years (copying and manually adjusting scripts from ripgrep is not a fun task let alone creating release pipelines from scratch). I am using cargo-dist for https://github.com/FroVolod/near-social now 🎉

[Be-ing]

Preferring statically linked musl can work okay until you need to dynamically link C/C++ libraries.

[Gankra]

I poked at this a bit yesterday, but mostly hit problems with a lack of properly reproducible linux environment. I think my wsl2 ubuntu already had musl-tools installed, and getting Ubuntu to forget them proved unfruitful. I'll need to set up proper docker images or something to be able to reliably reproduce "out of the box" states for a few major linux distros.

That or don't care about helping people set things up locally and just focus on the Github CI env (disappointing).

[frol]

Setting up musl cross-compilation environment for every distro out there is not rewarding at all, which is why cross exists. Cross is used by ripgrep and a couple of other crates I saw around.

[bjorn3]

Something a lot more subtle that may be a reason not to use musl by default is that musl doesn't support DNS over TCP by design, so if a DNS response doesn't fit in a UDP packet it will get silently truncated. I did expect issues caused by this to be non-trivial to debug unless you actually know about this fact.

Edit: As pointed out by @panekj musl supports TCP fallback since about half a year.

By the way you may want to explicitly set -Ctarget-feature=+crt-static as the musl target may switch to dynamic linking by default in the future and musl based linux distros already patch rustc to make it dynamically link musl by default.

[Gankra]

MUSL DISTROS PLEASE NO

PLEASE

[Be-ing]

rust-lang/compiler-team#422

[panekj]

Something a lot more subtle that may be a reason not to use musl by default is that musl doesn't support DNS over TCP by design, so if a DNS response doesn't fit in a UDP packet it will get silently truncated. I did expect issues caused by this to be non-trivial to debug unless you actually know about this fact.

Hi, this is not correct. musl has support for DNS over TCP

By the way you may want to explicitly set -Ctarget-feature=+crt-static as the musl target may switch to dynamic linking by default in the future and musl based linux distros already patch rustc to make it dynamically link musl by default.

MUSL DISTROS PLEASE NO

PLEASE

Yes, please, because static linking has been broken for a very very long time and you should not be using static linking unless absolutely necessary (via specifying crt-static and other compiler options).

[bjorn3]

Hi, this is not correct. musl has support for DNS over TCP

Great to hear that it is now implemented. Seems that commit is less than half a year old and I hadn't rechecked after it landed.

[ericonr]

the features that require udev and dbus usually need to be feature-flagged and disabled in musl context

@frol Whatever gave you that impression? glibc knows nothing about udev or dbus, and neither does musl, because those layers sit on top of the C library, not below it

[bjorn3]

If you have a glibc based distribution, libudev.so and libdbus.so are compiled for glibc and thus don't work with musl. And if you have a musl based distribution, the musl versions would be dynamically linked, thus still breaking on glibc distros at runtime. You did have to statically link a musl version of libudev and libdbus, which may be harder than just disabling udev and dbus support entirely.

[ericonr]

So the issue is about cross compilation and static linking, not musl specifically.

Building on a musl-based distro is considerably easier, and there's a good chance static libraries for these will be available on that distro.

Either way, thanks for clarifying

[nbittich]

+1 for musl support. If you target gnu + musl, the release.yml file produced doesn't seem correct.