2022-08-22 release updated GLIBC version dependency

[Duckilicious]

Was this a conscious decision? Can you revert it? It currently means that I can't use the latest release of rust-analyzer on my AL2 machine without attempting to do something as risky as updating my GLIBC...

./rust-analyzer-x86_64-unknown-linux-gnu
./rust-analyzer-x86_64-unknown-linux-gnu: /lib64/libc.so.6: version `GLIBC_2.29' not found (required by ./rust-analyzer-x86_64-unknown-linux-gnu)
./rust-analyzer-x86_64-unknown-linux-gnu: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by ./rust-analyzer-x86_64-unknown-linux-gnu)

[lnicola]

Yes, https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/.

You can use rustup to install a version that's more compatible with older operating systems.

[kamulos]

Is there any documentation how to solve this? I am stuck to develop on Ubuntu 18.04 (which is still maintained) and need some guidance how to get it working.

• Rustup does not seem to give me a rust-analyzer for 1.63.0
• How would I configure the vscode extension to use the rustup binary instead of it's own one?

[lnicola]

You need to install a nightly (or beta?) toolchain and the rust-analyzer component: rustup toolchain install nightly --component rust-analyzer. You don't need to actually use that toolchain, only have it installed. Then you can set rust-analyzer.server.path in the Code settings to point to it, e.g. ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rust-analyzer.

Keep in mind that the nightlies are usually a couple of days behind the releases in this repository. This isn't a problem most of the time, but it's possible that some features like the custom commands won't function correctly. beta and in the future soon stable will lag more, since we don't currently backport the releases.

And of course, you can disable automatic updates and keep using an old version of RA, it should keep working in the future.

[kamulos]

Thank you. I think this mostly works. I got a few panics initially, but am currently not able to reproduce them.

To be honest I would much prefer something like a musl built static rust-analyzer if cross-compilation for an old glibc is not possible.

[lnicola]

To be honest I would much prefer something like a musl built static rust-analyzer if cross-compilation for an old glibc is not possible.

Do you mean this one? I recommend against using it because proc macros won't work there -- AFAIK, there's no dlopen in a dynamically statically-linked MUSL.

[bjorn3]

dlopen is supported by dynamically linked musl, but not statically linked musl. However if you use a musl rust-analyzer, you also need to use a musl rustc and vice versa to make proc macros work. Proc macros are linked against the same libc as rustc so that rustc can dlopen them at runtime and rust-analyzer needs to use the same libc so that it too can dlopen them at runtime.

[Veykril]

However if you use a musl rust-analyzer, you also need to use a musl rustc and vice versa to make proc macros work. Proc macros are linked against the same libc as rustc so that rustc can dlopen them at runtime and rust-analyzer needs to use the same libc so that it too can dlopen them at runtime.

Wouldn't that be solved by the proc-macro-srv rustup component we now have? Since that is build the same as rustc (when the rustup component is being used that is).

[bjorn3]

proc-macro-srv is not yet on stable, right? Once it is, yes it would be fixed I think.

[lnicola]

I think we caught the beta train, so it should be there in the next release.

But the MUSL build was slower IIRC, I still don't think we should bundle that version instead.

[bjorn3]

Would using jemalloc as allocator help with performance? I would guess that musl's allocator is slower than glibc's and that this is the cause for the perf regression.

[lnicola]

I think we tested once and jemalloc and LTO and whatever made the MUSL version about as fast as the vanilla GLIBC one.

Though MUSL 1.2.1 should have an improved allocator, but I didn't test it.

[lnicola]

CC #13086

[danilaml]

Maybe you can use https://github.com/messense/cargo-zigbuild to cross-compile/target older glibc.

[jhgg]

This is going to cause pain for every single rust developer at my org, because our current developer VM is, and will be, for at least the rest of the year, and probably into next year, be Ubuntu 18.04 :/

I really think rust-analyzer needs to provide advanced notice for this.

[lnicola]

If you're affected by this, the easiest way to roll back to 0.3.1170 from this menu:

We've actually used Ubuntu 20.04 before, between #10672 and #11593. This was discussed before in #11558.

[hanbu97]

If it is possible to fork a version on vscode market which supports old system version like ubuntu 18.04.

[hanbu97]

If you're affected by this, the easiest way to roll back to 0.3.1170 from this menu:

When I try to roll back to old vrsion by "install another version", it does not work in most cases(after click, nothing happened). Also, it's quite unclear to stop auto update extension(for remote environment).

[wasd96040501]

If you're affected by this, the easiest way to roll back to 0.3.1170 from this menu:

When I try to roll back to old vrsion by "install another version", it does not work in most cases(after click, nothing happened). Also, it's quite unclear to stop auto update extension(for remote environment).

@hanbu97 Maybe it is slow. After 1~2 minutes it will show. It is exactly what I experienced.

[IGTHORN]

I am using a local dev container. Recreating the container with bullseye instead of buster allows 0.3.1186 to run successfully. Hope that helps someone.

[zhengcan]

As workaround, I compile rust-analyzer manually, and replace the bundled one in vscode-server.
It works very well as before.

git clone https://github.com/rust-lang/rust-analyzer/
cd rust-analyzer
cargo build --release
cp target/release/rust-analyzer ~/.vscode-server/extensions/rust-lang.rust-analyzer-0.3.1186-linux-x64/server/rust-analyzer

[ztsweet]

thanks

[cuviper]

If you decide to improve the compatibility of the non-rustup released binaries, you might look at how rustup itself borrows the docker images we create in rust-lang/rust dist CI.

[taikulawo]

There are many people have to use older OS release version for some reason. I don't understand why RA upgrade build system again and again without consider compatibility, broken ours workflow and toolchains.

[hax10]

If you're affected by this, the easiest way to roll back to 0.3.1170 from this menu:

When I try to roll back to old vrsion by "install another version", it does not work in most cases(after click, nothing happened). Also, it's quite unclear to stop auto update extension(for remote environment).

@hanbu97 Maybe it is slow. After 1~2 minutes it will show. It is exactly what I experienced.

I am having the same problem with slow / unreliable downgrades via the VS Code user interface.

I ended up downgrading manually.

If you are running a 64-bit Linux system, you can download 0.3.1170 from here:

https://github.com/rust-lang/rust-analyzer/releases/download/2022-08-15/rust-analyzer-linux-x64.vsix

and install via the command-line

# cd into the folder where you downloaded the extension
code --install-extension rust-analyzer-linux-x64.vsix

And disable auto-updates using File > Preferences > Settings, search for extensions.autoUpdate and disable Extensions: Auto Update.

[hanbu97]

Thank you @hax10. I used the method introduced by @zhengcan , which is quite straitforward. It works so far so good.

[hax10]

@hanbu97 Yes, I think the method from @zhengcan is best when you already have a version of Rust Analyzer installed.

My method is for new VS Code installations without Rust Analyzer.

[LighthouseJ]

This should be reopened and reverted because this breaks automated tools that run in environments like docker that makes it very difficult to compile RA into it.

[lnicola]

I don't understand why RA upgrade build system again and again without consider compatibility, broken ours workflow and toolchains.

Because GitHub dropped the outdated builder. We currently use their VMs to build the binaries, so we had to upgrade to the newer version of the distro.

This should be reopened and reverted because this breaks automated tools that run in environments like docker that makes it very difficult to compile RA into it.

Docker makes it easy to build from source, you don't depend on the binaries here.

[flodiebold]

This should be reopened and reverted because this breaks automated tools that run in environments like docker that makes it very difficult to compile RA into it.

What automated tools do you have running rust-analyzer?

[JosuGZ]

Because GitHub dropped the outdated builder. We currently use their VMs to build the binaries, so we had to upgrade to the newer version of the distro.

How about not using GitHub to build it? Now GitHub decides to break the workflow of lots of users? A tool that suddenly stops working is not a tool one can rely on.

[bjorn3]

Have you seen the rustup component for rust-analyzer? You can use rustup install --toolchain nightly rust-analyzer (using beta as toolchain works too, stable will work with the next release) and then use rustup +nightly which rust-analyzer to find the path and point the rust-analyzer.server.path config to it. This version of rust-analyzer has the same glibc requirement as rustc as it is built in the same environment.

[JosuGZ]

Have you seen the rustup component for rust-analyzer? You can use rustup install --toolchain nightly rust-analyzer (using beta as toolchain works too, stable will work with the next release) and then use rustup +nightly which rust-analyzer to find the path and point the rust-analyzer.server.path config to it. This version of rust-analyzer has the same glibc requirement as rustc as it is built in the same environment.

Yeah there is always a solution. But this is still a bug and should be treated as such IMO. And I guess I will have to switch back to stable later.

[bjorn3]

I did say that the fault is with glibc requiring programs compiled on a system with one version of glibc to only run on systems with at least that version of glibc even if all functions from glibc used by the program are available on earlier glibc versions. For as long as they don't fix that issue, everyone building glibc based programs has to complicate their CI by a lot to produce programs capable of running on older systems. This problem is unique to glibc (ignoring OSes that don't have any binary compatibility at all). Other linux libc implementations like musl don't have the same issue and neither do Windows and macOS.

[lnicola]

even if all functions from glibc used by the program are available on earlier glibc versions

They aren't. I think there must have been a change in the standard library that made programs call some newer functions (statx and something related to posix_spawn) when available.

And I guess I will have to switch back to stable later.

You don't need to use the beta or nightly toolchain to compile your programs, you just need RA from there. It will be promoted to stable in 13 days.

But this is still a bug and should be treated as such IMO.

There are other, more important, platforms like Windows 32-bit for which we don't have binaries. Not even the Rust compiler is available on all platforms that Rust supports.

If you still think this is a bug and I don't get a chance to do something about it this week-end, feel free to submit a pull request to fix it. Such are the ways of open-source.

[cuviper]

Adding to my earlier comment, here is the script that rustup uses to get the docker images from rust CI:
https://github.com/rust-lang/rustup/blob/master/ci/fetch-rust-docker.bash

I haven't looked at rust-analyzer's release process, but if it is updated to use the same images, it will end up with the same ABI compatibility as the rest of the rust toolchain. And we do know the RA build can technically work in that environment, because we are already building the rust-analyzer component that way to be shipped in rustup channels.

[JosuGZ]

There are other, more important, platforms like Windows 32-bit for which we don't have binaries. Not even the Rust compiler is available on all platforms that Rust supports.

IMO not having something available for a platform is not a bug. Suddenly opening VS Code and having to figure out why nothing is working, installing all updates and nothing, and having to search on the Internet, is a bug.

Ideally, this would not happen. But if it is going to happen, at least RA should give us a nice message explaining it is no longer supporting certain platforms and providing instructions to fix it via rustup. It could also have the ability to fall back to an older version.

If the project can't provide some stability perhaps it should release less frequently. It is the third time it breaks for me recently. Perhaps it has been just bad luck but this is starting to feel like JavaScript tooling 😆 Just my thoughts.

[LighthouseJ]

This should be reopened and reverted because this breaks automated tools that run in environments like docker that makes it very difficult to compile RA into it.

What automated tools do you have running rust-analyzer?

This morning, I tried to use docker desktop to create a dev environment container and develop inside of it with VSC.
It's a feature in beta: https://docs.docker.com/desktop/dev-environments/

I couldn't use the environment because VSC couldn't run RA specifically for this error, and I can't realistically build RA inside of that docker image.