Try to build with musl on CI

[ConradIrwin]

• Closes Static compilation of remote server with musl #19092
• Closes Add support for NixOS as a Dev server in remote development. #15411

Release Notes:

• SSH Remoting: Build with musl (adds support for machines with old, or no glibc)

[osiewicz]

Would it make sense to also check for libc here?

[stalkerg]

rustup target add "$musl_triple" -- this line break build for Linux where rust controls by pkg manager.

Also, why by default you want to use musl? On my system default is glibc and I want to use it.

[SomeoneToIgnore]

this line break build for Linux where rust controls by pkg manager.

We strongly rely on the rustc version from https://github.com/zed-industries/zed/blob/main/rust-toolchain.toml and do not guarantee that other set-ups work.
This file needs rustup to function automatically, hence we strongly rely on it too.

Other people with alternatives should know what they are doing and are expected to handle fall-outs of their cleverness themselves.

Also, why by default you want to use musl?

Because Linux is extremely fragmented and libc is yet another part of this, and it is chore to maintain various builds for other people who want their things.

Just because of some not-dead-yet-but-in-6-months-maybe EOL Ubuntu we have to do all this work:

#17643
#18442

And much more, as now we have ssh remoting, which ascends this chore to the next level, as we're

• either supposed to somehow detect libc on the client, find the right build and upload it there (or, worse, in the dev mode, when building from one system to another, deal with some docker fiddling even on Linux, to get the right build for target's libc)

• or just use musl and it seems to "just work" (for now, at least)

The latter seems much more practical, as we have a huge backlog already, without fighting with libc.

and I want to use it.

Religious preferences aside, any other reason for that?

And I want to stop dealing with libc issues once and for all.
What is a good way to do this?

[stalkerg]

rustup is

rustup is an installer for the systems programming language Rust

it's not part of toolchain, and as developer I want to have my own way to install rust.

Just because of some not-dead-yet-but-in-6-months-maybe EOL Ubuntu we have to do all this work:

thank you! It's a good tickets to understand situation. Because I build Zed by myself I have no a such issue, I think build scripts should be good enough to produce not only static bin for publication but also system level builds. Most apps what I am using everyday have no issue to build it specially for my system with my libc. Especial because musl can break a lot of things for Linux. Mixing 2 libc (in app and system) can produce a lot of issues. (I shared links in my ticket)

Religious preferences aside, any other reason for that?

it's not religious, it's just how I use Zed on my Gentoo Linux. I believe many others who will be prefer to build zed by themself (for development for example) can have the same issue (not only on Gentoo).

[SomeoneToIgnore]

it's not part of toolchain, and as developer I want to have my own way to install rust.

And you're welcome to do so without coming here and demanding reverts, since

Other people with alternatives should know what they are doing and are expected to handle fall-outs of their cleverness themselves.

For the rest of the users, there's a TFM here: https://github.com/zed-industries/zed/blob/c12a9f26733e0791ba99b015c3695712ae40322a/docs/src/development/linux.md and guess what is in the first bullet of the "Dependencies" section there.

You should have either seen this (and ignored, so the consequences are all yours to handle) or have not bothered to look at it at all (not sure why should I bother discussing things with you then).

The rest of the points seem to reinstate the same "I build myself and this is how I want things" position, so see above of this comment for them.

---

Not even sure why are we continuing this discussion, this will be my last message here (I'll comment on the closed issue too, once):

• as a Gentoo user, you're perfectly able to build whatever set of patches and build scripts on top of this repo (as it seems to be relatively standard for Gentoo ebuilds anyways? Care to create and publish one?)

• as a Zed company, we're focused on shipping editor binaries for people, in a most practical way. We have our own compromises to make which may not align with some users' workflows, alas — it seems impossible to please all Linux users.

[stalkerg]

Thank you for explanation your position. I did revert of this commit by myself and plan to prepare my script.
Sorry, but last quick question - will you accept PR with changes to open possibility to build it locally without musl and rustup (as addition)?

[SomeoneToIgnore]

Hard to say without looking at the PR first.

If that changes things too much or adds more compromises or friction to our builds on top, we might not accept it, but overall the PRs are sure welcome.

I would personally prefer a PR (if it had some effort and testing in it) over any discussion(s), as words in the issues are dust; it's the code that gets shipped.

[panekj]

Please mind that while musl triple in Rust is currently producing statically linked objects (for some targets), this will be changed in future. Anyone relying on that behaviour should explicitly pass -C target-feature=+crt-static to avoid breakage. More info available here: rust-lang/compiler-team#422 | Example of already dynamically linked musl targets: rust-lang/rust@a937a3b

[SomeoneToIgnore]

Thank you a lot for this bit, added the flag with #19813