Check /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20', `GLIBCXX_3.4.21' by default

[mengjuleu]

Description

In 1.408-vsc1.32.0, it seems code-server check GLIBCXX_3.4.20 and GLIBCXX_3.4.21 before anything starts. Therefore, it's almost impossible to run code-server in CentOS 7. We can run code-server 1.32.0-310 by replacing spdlog.node in $HOME/.local/share/code-server/dependencies. Is there any similar way in 1.408-vsc1.32.0?

[LongQIByte]

apt-get install software-properties-common
add-apt-repository ppa:ubuntu-toolchain-r/test
apt-get update
apt-get upgrade
apt-get install gcc-4.9
apt-get upgrade libstdc++6

Have you changed the dockerfile?

[mengjuleu]

@JavanTang I used CentOS 7

[LongQIByte]

@mengjuleu You can use yum to install apt and then use those commands. I have not tried it, just give a way.

[robopuff]

@JavanTang That is least effective way to do it in any other distro than Ubuntu. I have for example a Debian Jessie (Debian 8) and solution provided by you won't work at all.

[jakegt1]

Seems that the binary itself needs that glibc version now.

It would be nice if the binaries were actually built on CentOS (or a different flavour of linux with older GCC) so CentOS users could also use code-server.

The docker implementation is nice, but it's not great for long-lived usage.

[lunedam-git]

Was genuinely excited about this until I discovered that it wouldn't run on CentOS 7. Such a shame. Hopefully a binary compiled for people who dare to not use Ubuntu will become available 😉

[mengjuleu]

Well, I finally found a way. I compiled and installed gcc 8.3 on my CentOS 7 box. Then create symLink to the newer libstdc++.so.6 under /lib64 so that code-server can pick up the newer version of c++ lib.

BTW, compiling code-server on CentOS 7 box won't help, it'll still show the same error message when launching.

[ymmt2005]

Linking with g++ -static-libgcc -static-libstdc++ may help.

[mischajonker]

It seems that in the most recent binary drop, the environment is not passed correctly when creating the shared process. This causes LD_LIBRARY_PATH to not be passed, which results into the error message related to GLIBCXX_3.4.20 if you're running on CentOS 7.
It worked fine with the v1.31.1-100 binary drop.

When doing a strace -ff, you will see:
strace.pid.14450:execve("....../code-server/code-server", ["..../code-ser"..., "/home/travis/build/codercom/code"..., "--bootstrap-fork", "vs/code/electron-browser/sharedP"..., "--extra-args", "[]", "--data-dir", "......./.local/share/code-ser"...], [/ 3 vars */]*) = 0

So, only 3 variables are passed as environment to execve syscall, while I have 159 in my environment...

[mengjuleu]

@mischajonker Yeah, I found the same thing. So, the shared process cannot catch up LD_LIBRARY_PATH env var. So, I still need to create symLink lin /lib64 which is dangerous.

[mischajonker]

... and not to mention that creating a symLink in /lib64 requires root, which I don't have. Perhaps we need to change this issue from "question" to "bug".

[Gr33nChip]

... and not to mention that creating a symLink in /lib64 requires root, which I don't have. Perhaps we need to change this issue from "question" to "bug".

I agree, it looks like it have effected all centos users. :( i dont want to change os just to get this to work :(

[jeasonstudio]

... and not to mention that creating a symLink in /lib64 requires root, which I don't have. Perhaps we need to change this issue from "question" to "bug".

Also urgent label.

[mal2]

I had the same problem on debian jessie, i think i fixed it by adding -D_GLIBCXX_USE_CXX11_ABI=0 to the "cflags" in code-server/packages/protocol/node_modules/spdlog/build/config.gypi
...
3 "target_defaults": {
4 "cflags": ["-D_GLIBCXX_USE_CXX11_ABI=0"],
5 "default_configuration": "Release",
...

but got the SyntaxError: Unexpected end of JSON input error now