VS Code Server not work at CentOS7, Inconsistent with the doc

[CberYellowstone]

The doc said

Requires kernel >= 3.10, glibc >= 2.17, libstdc++ >= 3.4.18. RHEL / CentOS < 7 does not meet this requirement without using a workaround to upgrade.

and my CentOS7 environment is:

[root@localhost ~]# strings /lib64/libstdc++.so.6 | grep LIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_DEBUG_MESSAGE_LENGTH

and

[root@localhost ~]# ldd --version ldd (GNU libc) 2.17 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and

[root@localhost ~]# cat /proc/version Linux version 3.10.0-1160.66.1.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Wed May 18 16:02:34 UTC 2022

but while i run code-server,

[root@localhost ~]# /usr/local/bin/code-server /usr/local/bin/code-server: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /usr/local/bin/code-server) /usr/local/bin/code-server: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/bin/code-server)

more information:

[root@localhost ~]# strings /usr/lib64/libc.so.6 |grep GLIBC_2 GLIBC_2.2.5 GLIBC_2.2.6 GLIBC_2.3 GLIBC_2.3.2 GLIBC_2.3.3 GLIBC_2.3.4 GLIBC_2.4 GLIBC_2.5 GLIBC_2.6 GLIBC_2.7 GLIBC_2.8 GLIBC_2.9 GLIBC_2.10 GLIBC_2.11 GLIBC_2.12 GLIBC_2.13 GLIBC_2.14 GLIBC_2.15 GLIBC_2.16 GLIBC_2.17

Hope fix this problem, thx

[connor4312]

More dynamic linking fun.

It looks like this can be avoided if we statically link again musl using the x86_64-unknown-linux-musl target rather than dynamically linking against GNU libc, and I was able to build the CLI without issues by just swapping the target and installing musl-tools. VS Code itself will still require specific libc versions, but that removes at least some entropy from the system.

Downsides are:

• I expected binary size to be a bit bigger, it's <100KB larger
• The musl allocator is slower. It's improved since older versions, but still slower than gnu's.
  • I have not measured what performance impact this has on the CLI. We do allocate when ferrying packets between the tunnel and server, but this is still pretty 'lightweight' work strongly limited by network latency rather than CPU.
  • A commonly suggested solution, swapping in jemalloc, increasing binary size from 9.3MB to 9.7MB. However, there are not existing jemalloc bindings for Rust that support all of our targets.

[CberYellowstone]

More dynamic linking fun.

It looks like this can be avoided if we statically link again musl using the x86_64-unknown-linux-musl target rather than dynamically linking against GNU libc, and I was able to build the CLI without issues by just swapping the target and installing musl-tools. VS Code itself will still require specific libc versions, but that removes at least some entropy from the system.

Downsides are:

• I expected binary size to be a bit bigger, it's <100KB larger

• The musl allocator is slower. It's improved since older versions, but still slower than gnu's.

  • I have not measured what performance impact this has on the CLI. We do allocate when ferrying packets between the tunnel and server, but this is still pretty 'lightweight' work strongly limited by network latency rather than CPU.
  • A commonly suggested solution, swapping in jemalloc, increasing binary size from 9.3MB to 9.7MB. However, there are not existing jemalloc bindings for Rust that support all of our targets.

Perhaps you could change the installation script to use a dedicated binary package when you identify centos 7 and other special systems? This way you don't need to change it on other systems

[jasonwzz]

Any update here? Any way we can experiment with the centos7 compatible version? Thanks!

[CberYellowstone]

@connor4312 @tanhakabir Any update?

[goodseog]

@bamurtaugh Any update?

[bamurtaugh]

Thanks for following up! This is on our team's backlog, and we'll certainly update the issue with any updates as they happen.

[connor4312]

I looked at a few approaches to this. I still kept the glibc target around, but we had to make a musl build to target Alpine Linux anyway. And thus I have made the setup script automatically install that version if the version of glibc is too old or not detected, thus this should now work 🙂

[muuuh]

Thank you. I assume that the file https://aka.ms/vscode-server-launcher/x86_64-unknown-linux-musl will be provided in the near future?

The link from the setup script https://aka.ms/install-vscode-server/setup.sh does not seem to work at the moment.

[connor4312]

Sorry, that should be active in a few minutes...

[connor4312]

Looks like I get a Segmentation Fault trying to run the musl binary. I will continue to look into this over the next day or so...

[connor4312]

This is now fixed 🙂

[Vanbob-Lee]

@connor4312 Hi. I use Debian9, and also meet the glibc version problem. I try reinstall code-server today but still not work. Could you help to check this?

2022-09-23 10:36:38 (85.8 MB/s) - written to stdout [1758/1758]

glibc version is 2.24 is min? 1 Installing from https://aka.ms/vscode-server-launcher/x86_64-unknown-linux-gnu ➜ ~ code-server code-server: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by code-server)