Consider building static MUSL binaries

[lnicola]

Our MUSL version is dynamically linked (for Alpine), but some users might just want a binary that works more or less everywhere. Perhaps we should build that, too (not sure under what name/target tuple), and maybe use it in the VSIX.

Some benchmarks on analysis-stats self, best of four:

!lto musl
Total:               44.76s, 343ginstr

!lto gnu
Total:               40.33s, 325ginstr

lto musl
Total:               43.65s, 334ginstr

lto gnu
Total:               39.57s, 312ginstr

I didn't set codegen-units, but it looks like LTO might not be worth the trouble.

[veber-alex]

Maybe try to use the same build pipeline as rustc?
At the moment rustc supports RH 6 with a bump to RH 7 in the near future.
Feels bad to lose 10% performance just because github removed a runner.

[lnicola]

You can already install rust-analyzer using rustup and get a binary that works on RHEL 6. The rust-lang/rust CI setup is probably a bit more complex than what we want to have.

Feels bad to lose 10% performance just because github removed a runner.

Not because GitHub removed a runner, because some of the users don't want or can't upgrade their distro. GitHub is not at fault here.

[lnicola]

@bjorn3 do you know if there are some preferred ways to name targets with statically- or dynamically-linked libc? I suppose not, since it's the same target anyway, though.

[bjorn3]

Not that I know of.

[kamulos]

As one of the louder people to complain in the other thread, I want to soften my stance a little bit: I quite like the solution where the rust-analyzer is distributed with rustup.

It's really easy to install and when it is in the PATH, I just have to configure "rust-analyzer.server.path": "rust-analyzer" and everything works smoothly. I guess rust-lang/rustup#3022 will also help to easily provide it in the PATH.

I think the rustup distributed rust-analyzer will hit stable with 1.64.0 which I like a lot. Getting updates after a couple of months is absolutely fine for me, I absolutely don't need the new things every week.

What I am worried about is that this setup will also break regularly: usually our dev container is getting updates after a couple of Rust versions. This means in total the stable rust-analyzer could be 4 Months behind the vscode release. I guess sometimes the extension will already have evolved far beyond the stable channel rust-analyzer?

Also the error message for the failure of the bundled version on an old system should definitely be improved, if this is an officially recommended way to solve the issue.

[lnicola]

@kamulos it's totally fine to run rust-analyzer from a nightly toolchain. But you can also disable automatic updates on the extension.

[kamulos]

From a purely practical standpoint, this just does not seem great to me:

1. I tried installing just the nightly rust-analyzer with rustup but it installed all of the tools for me. Having to carry the size of the whole nightly toolchain in the dev container just for the one binary does not seem reasonable to me.

2. With our current processes, we update the dev container roughly every two months. So even if we had the nightly rust-analyzer it could very well be 2-3 months old. I think many companies will be even slower and they also need a solution.

3. Disabling updates seems to just work on a global level, not per extension. And then we would have the opposite issue: vscode extensions need to be updated manually. And even worse: every developer needs to do this manually on their machine.

I am just trying to find a pragmatic solution for my situation. Companies with slower updates will certainly always be there, and having a smooth, recommended way for us would be really great :)

[veber-alex]

What about trying cargo zigbuild to build against an older glibc on the new image?

[12101111]

musl don't support dlopen in static build: https://github.com/bminor/musl/blob/v1.2.3/src/ldso/dlopen.c#L6

But rust-analyzer need dlopen to handle proc-macro.

[lnicola]

Our x86_64-unknown-linux-gnu binaries are now built, for better or worse, on Ubuntu 18.04 (EOL April 30).

musl don't support dlopen in static build

I knew that, so I don't know what I meant by opening this issue. Maybe I was thinking of a version that works except for the proc macros, but that would be terribly confusing for users ("I got the static binary because I love musl, but it doesn't work with serde").

So no, this seems like an awful idea.