Skip to content

[Bug][IDE]: VSCode extension doesn't work with GLIBC 2.34 #163

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
alexanderpils opened this issue May 6, 2025 · 3 comments
Open

[Bug][IDE]: VSCode extension doesn't work with GLIBC 2.34 #163

alexanderpils opened this issue May 6, 2025 · 3 comments

Comments

@alexanderpils
Copy link

Describe the Bug

I wanted to try out the VSCode extension, but got this error, it seems I have a too old version of GLIBC (2.34) but 2.39 is needed, therefor I am not sure if this is a bug or it's just on my side, but sadly I can't update this system, so maybe there is the option to lower the required version.

Codebase

No response

IDE Setup

I am running pyrefly 0.14.0
VSCode 1.99.3
CentOS Stream 9

Output

/home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/bin/release/pyrefly: /usr/lib64/libc.so.6: version `GLIBC_2.39' not found (required by /home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/bin/release/pyrefly) [Error - 7:06:37 AM] Client Pyrefly language server: connection to server is erroring. Shutting down server. [Error - 7:06:37 AM] Stopping server failed Error: Client is not running and can't be stopped. It's current state is: starting at xd.shutdown (/home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/dist/extension.js:39:8615) at xd.stop (/home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/dist/extension.js:39:8194) at xd.stop (/home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/dist/extension.js:39:44100) at xd.handleConnectionError (/home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/dist/extension.js:39:13955) at processTicksAndRejections (node:internal/process/task_queues:95:5) at runNextTicks (node:internal/process/task_queues:64:3) at process.processImmediate (node:internal/timers:454:9) [Error - 7:06:37 AM] Server initialization failed. Message: write EPIPE Code: -32099 [Error - 7:06:37 AM] Pyrefly language server client: couldn't create connection to server. Message: write EPIPE Code: -32099 [Error - 7:06:37 AM] Restarting server failed Message: write EPIPE Code: -32099 [Error - 7:06:37 AM] The Pyrefly language server server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information. /home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/bin/release/pyrefly: /usr/lib64/libc.so.6: version `GLIBC_2.39' not found (required by /home/user/.vscode-server/extensions/meta.pyrefly-0.14.0-linux-x64/bin/release/pyrefly)

Other Attempts

No response

@SamChou19815
Copy link
Contributor

We can potentially use a older ubuntu image to produce the linux build that has a lower glibc requirement. However, the oldest one provided by GitHub is ubuntu 22.04, which requires glibc 2.35, so unfortunately it still won't solve your problem.

@alexanderpils
Copy link
Author

You're right — that wouldn't solve my issue, but I’d still recommend providing wheels for Ubuntu 22.04. Its end-of-life is in 2027, so it’s still widely used.

That said, I’m not deeply familiar with the intricacies of this topic, so I might be off base. However, I use Ruff — which is also built with Rust and relies on glibc — and it works well on my system. Perhaps there's an opportunity to follow a similar approach to how they build their wheels? From what I can tell, they use the manylinux image and glibc 2.17+.

@kinto0
Copy link
Contributor

kinto0 commented May 9, 2025

We have a few options:

  • Build with musl for statically-linked dependencies. I bet this would impact our performance and we'd have to benchmark it (source)
  • use an image from an older OS like ubuntu 20.04

I tried option 2 and it seems to build. can you test that this extension works on your machine?

pyrefly-linux-x64.zip

facebook-github-bot pushed a commit that referenced this issue May 9, 2025
Summary:
Older operating systems have an older glibc version that won't work with newer versions. But newer versions always work with older version. When a version is too old, our binary fails to start with a message like `version `GLIBC_2.39' not found` (User report [here](#163)).

Ubuntu 22.04 is the oldest version [github will support by default](https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories). By building on ubuntu-latest, [we build on ubuntu 24.04](https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories). But this does not work with older operating systems like ubuntu 22.04 or CentOS 9. Ubuntu 20.04 is EOL end of may 2025 and no longer receives security updates. But CentOS 9 gets updates until 2027. If we build on ubuntu 20.04, we can target CentOS 9 and other older systems.

We have a few options in resolving this:
- build with musl for a statically-linked self-contained binary. Downsides: [known perf regressions](rust-lang/rust-analyzer#16793 (comment)) (I have not benchmarked this). All OS versions (even new ones) will get the `musl` build because there is no way to target older OSes in VSCode's release
- build with an older OS github supports natively like ubuntu 22.04
- build with an even older OS with a custom container

This diff implements option 3 for the extension build. If we like it, we can also use it on the pypi build.

Is it worth it? Should we just target 22.04+? Or should we build with musl?

Reviewed By: SamChou19815

Differential Revision: D74490281

fbshipit-source-id: c904d2bff7e64b2527ef1839cff8a2cd77dc4724
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants