code-server: The latest cli (1.32.0-245) cause "ERROR SHARED stderr {"data": "Error: /lib64/libstdc++.so.64: version `GLIBCXX_3.4.21` not found"....
Description
Hi, the above problem raised when “Starting shared process[x/5]”, after I update my code-server cli from 1.31.1-100 to 1.32.0-245. It works properly when using the former version. I am wondering whether the latest cli depends on different C++ library from the former one?
PS: The message is: INFO Starting shared process [1/5]… ERROR SHARED stderr {“data”:"Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21’ not found (required by /path/to/my/home/.local/share/code-server/dependencies/spdlog.node)\n…
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 19
- Comments: 45 (3 by maintainers)
Working on a fix for this right now. If all goes well, we’ll have a working CentOS build today!
Cry? /s
not sure… I’ll poke around again… I know I had this exact issue but I ended up fixing it at some point…
$ npm --version 6.9.0 $ node --version v8.15.0 $ yarn --version 1.13.0
maybe npm update?
npm install -g npmForget about this, you guys. VSCode Insiders has an extension released by Microsoft called “Remote Development” which does the same thing as this, and it actually works.
A working CentOS build today?
@kylecarbs this is the output of the latest version:
I found out that this problem is (for me) caused by the “spdlog.node” binary. I ended up rebuilding that binary from the repo at https://github.com/Microsoft/node-spdlog… And while I have no idea about how to look into the build process of this project, I presume it doesnt build that binary itself but rather downloads it as a dependency (I mean, my system doesnt HAVE a 3.4.21 GLIBCC header to build with, so this has to be the case). Building node-spdlog does NOT take long at all (a few seconds) so I would suggest that this project should build it itself (it also builds a lot of stuff with gcc compiler in general, so adding this would make the builds more OS independent)
EDIT: At the same time, I somehow ruined everything and through cleanups and all, it wouldn’t build the cli-linux-x64 binary anymore (which is code-server), but that’s unrelated to this issue
I’m on Centos 7, just installed/upgraded to latest libstdc++ offered, same issue.
and before this:
@FractalBoy - remote development vs online ide have one big difference - online ride is not using your local resources (CPU and RAM). It can be critical in some cases.
What to do now? 😃
Still got the same error message:
I also tried to run with LD_LIBRARY_PATH but I cannot start share process successfully.
Might be fixed with the latest release.
We lowered the GLIBC version required. Might be able to work on older versions now.
I resolved this issue by install gcc-9.1.0 (
gcc-9.1.0.tar.gz) manually in CentOS 7.https://gcc.gnu.org/mirrors.htmlMy version:
code-server1.1156-vsc1.33.1-linux-x64@EasySoftwarePoland indeed ! the reason why i’m interested with this is to use the physical resource for one of my servers.
In version 1.31.1-100, it’s effective to use LD_LIBRARRY_PATH. But, this approach is no longer valid in later versions. That confuses me.
The same problem Ubuntu “18.04.2 LTS (Bionic Beaver)” (it’s google cloud Ubuntu mini )