Update rpm dependencies file for newer CXXABI requirement #115784

tazerdev · 2021-02-04T18:06:49Z

VS Code Version: 1.53.0
OS: RHEL7.9

Error:
The terminal process failed to launch: A native exception occurred during launch (/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/node-pty/build/Release/pty.node)).

$ strings /lib64/libstdc++.so.6 | grep CXXABI
CXXABI_1.3
CXXABI_1.3.1
CXXABI_1.3.2
CXXABI_1.3.3
CXXABI_1.3.4
CXXABI_1.3.5
CXXABI_1.3.6
CXXABI_1.3.7
CXXABI_TM_1

The text was updated successfully, but these errors were encountered:

vscodebot · 2021-02-04T18:06:52Z

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

gjsjohnmurray · 2021-02-04T19:35:18Z

See Breaking Change section at https://code.visualstudio.com/updates/v1_53#_performance-improvements

gjsjohnmurray · 2021-02-04T19:36:52Z

Better link https://code.visualstudio.com/updates/v1_53#_electron-11-update

dcourtois · 2021-02-05T10:33:47Z

Same issue here. Unfortunately CentOS 7 is still wildly use in some areas, and the links pointed to by @gjsjohnmurray explains the cause, but unfortunately doesn't provide any workaround.
Is there any workaround known at this point ? This is a pretty important issue, right now VSCode is just not usable: git doesn't work nor the terminal and most of the extensions like C/C++, CMake Tools, etc. It's reverted to a simple text editor)

tazerdev · 2021-02-05T10:52:01Z

From the changelog:

With these changes, the following are the distros known to work for the x64 desktop app:
Ubuntu 16.04 and newer
Fedora 24 and newer
Debian 9 and newer
CentOS 8 and newer
Note: Our remote development components continue to use GLIBCXX 3.4.19, so there is no change in supported platforms.

So I guess my next question would be why, if it's no longer a supported platform, is CentOS7 being given an RPM that's meant for CentOS8?

gjsjohnmurray · 2021-02-05T11:11:25Z

Is there any workaround known at this point ?

@dcourtois previous versions can be downloaded by going to https://code.visualstudio.com/updates and choosing the version from the sidebar, then using the download link on its release notes.

I assume you are using CentOS 7 as your desktop, right? And can't use any of the workarounds offered in the 1.53 release notes?

A workaround for the other distros would be to install gcc-5 or higher toolchain to avoid the GLIBCXX error with native modules, but there is no guarantee that all components of the runtime will work fine. There is also the option of using our remote development suite to work with the older distros.

RudiFueller · 2021-02-05T15:04:29Z

If you are affected by this issue, let me tell you what I did:

Download a recent gcc-tarball from a GNU mirror + compile
Take the content of x86_64-pc-linux-gnu/libstdc++-v3/src/.libs and copy to a dir of your choice (eg. ~/lib64/libstdc++-v3)
Write a start wrapper for vscode, put your extended LD_LIBRARY_PATH in the wrapper
Open vscode with the wrapper -> done.

Tyriar · 2021-02-05T15:34:41Z

Sorry but we needed to move forward to support the new version of Electron. Here are your options:

Upgrade your OS
If you're remoting into the machine you can use the remote development extensions or codespaces because this only affects Electron (desktop), not node (remote server)
Try install the compatible binaries as suggested above Update rpm dependencies file for newer CXXABI requirement #115784 (comment), YMMV with this approach
Use an older version of VS Code - not only will you miss out on new updates but also security updates so this isn't recommended

tazerdev · 2021-02-05T17:21:41Z

@Tyriar

Understood but the 1.53 RPM shouldn't install on a RHEL7/CentOS7 based system in the first place because RHEL7 has a standardized GLIBC that will be maintained throughout its lifecycle. The rpmspec should include a requires statement based on GLIBC version and the rpms should be provided in an EL compatible repository (i.e., RHEL7 and RHEL8 rpms are maintained in separate locations.)

As it stands VS Code is breaking the packaging standards of the platform and causing problems for users. If you can direct me to the appropriate area I'll gladly open a bug request there.

Tyriar · 2021-02-05T18:40:55Z

@tazerdev good point, @deepak1556 we need to update the deps in https://github.com/microsoft/vscode/blob/master/resources/linux/rpm/dependencies.json. Historically I just pull in whatever Chromium targets in their spec.

hardik-singhal · 2021-02-06T18:16:57Z

Unable to open vscode debugg console and terminal after vs code update. Is there any solution yet.
I am using centos 7 and can't install any library mention in the error**

elulcao · 2021-02-06T18:37:57Z

Not only Centos has been affected, but also other flavors like OL7 which is a variant of the RH7, etc...
Some env cannot be upgraded/updated for different reasons, so I guess VSCode needs to evaluate how to
make compatible again this new Drop of code1.53
Sharing the stack trace for tracking purpose.

cat /etc/*release
Oracle Linux Server release 7.9
NAME="Oracle Linux Server"
VERSION="7.9"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.9"
PRETTY_NAME="Oracle Linux Server 7.9"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:7:9:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 7"
ORACLE_BUGZILLA_PRODUCT_VERSION=7.9
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=7.9
Red Hat Enterprise Linux Server release 7.9 (Maipo)
Oracle Linux Server release 7.9

[16111:0206/123246.162480:INFO:CONSOLE(618)] "%c  ERR color: #f33 /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node): Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /usr/share/code/resources/app/node_modules.asar.unpacked/vscode-sqlite3/build/Release/sqlite.node)
    at process.func [as dlopen] (electron/js2c/asar_bundle.js:5:1812)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1250:18)
    at Object.func [as .node] (electron/js2c/asar_bundle.js:5:2039)
    at Module.load (internal/modules/cjs/loader.js:1039:32)
    at Module._load (internal/modules/cjs/loader.js:932:14)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
    at Module.require (internal/modules/cjs/loader.js:1079:19)
    at v (/usr/share/code/resources/app/out/vs/loader.js:3:12287)
    at Object.<anonymous> (/usr/share/code/resources/app/node_modules.asar/vscode-sqlite3/lib/sqlite3.js:1:77)
    at Module.u._compile (/usr/share/code/resources/app/out/vs/loader.js:3:12841)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
    at Module.load (internal/modules/cjs/loader.js:1039:32)
    at Module._load (internal/modules/cjs/loader.js:932:14)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12738)
    at Module.require (internal/modules/cjs/loader.js:1079:19)
    at require (internal/modules/cjs/helpers.js:72:18)
    at t (/usr/share/code/resources/app/out/vs/loader.js:4:101)
    at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:13249)
    at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
    at c (/usr/share/code/resources/app/out/vs/loader.js:4:10314)
    at Object.errorback (/usr/share/code/resources/app/out/vs/loader.js:4:10435)
    at r.triggerErrorback (/usr/share/code/resources/app/out/vs/loader.js:3:10626)
    at /usr/share/code/resources/app/out/vs/loader.js:3:10332
    at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:13266)
    at r.load (/usr/share/code/resources/app/out/vs/loader.js:3:10262)
    at c (/usr/share/code/resources/app/out/vs/loader.js:4:10314)
    at r._loadModule (/usr/share/code/resources/app/out/vs/loader.js:4:10444)
    at r._resolve (/usr/share/code/resources/app/out/vs/loader.js:5:452)
    at r.defineModule (/usr/share/code/resources/app/out/vs/loader.js:4:6145)
    at r._relativeRequire (/usr/share/code/resources/app/out/vs/loader.js:4:6831)
    at n (/usr/share/code/resources/app/out/vs/loader.js:4:9420)
    at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31382
    at new Promise (<anonymous>)
    at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31362
    at new Promise (<anonymous>)
    at n.doConnect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:31342)
    at n.connect (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:30812)
    at new n (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:21:28194)
    at Ot.doInitialize (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:16863)
    at Ot.initialize (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:29:16753)
    at M.init (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:47:2577)
    at new M (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:47:2523)
    at lt.openFirstWindow (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:55:82995)
    at /usr/share/code/resources/app/out/vs/code/electron-main/main.js:55:77462
    at E.invokeFunction (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:26:25463)
    at lt.startup (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:55:77438)
    at async Y.startup (/usr/share/code/resources/app/out/vs/code/electron-main/main.js:57:1448)", source: file:///usr/share/code/resources/app/out/vs/workbench/workbench.desktop.main.js (618)

markusdd · 2021-02-08T10:59:08Z

In my view this change is not acceptable. Especially RHEL7 and derivatives are very widely used in enterprise environments and there is no way just 'to upgrade' as usually other commercial tools (in our case EDA simulators) do not even exist yet for RHEL8.

This drops a bomb into the workflow of many I would suggest.

At least there should be a very clear documentation on how to work around this and this should also be tested continuously for new releases in my view.

The recommended remote server workflows are not compatbile with all IT setups where VS Code is being used.

arthurspa · 2021-06-22T12:39:43Z

If you are affected by this issue, let me tell you what I did:

Download a recent gcc-tarball from a GNU mirror + compile

Take the content of x86_64-pc-linux-gnu/libstdc++-v3/src/.libs and copy to a dir of your choice (eg. ~/lib64/libstdc++-v3)

Write a start wrapper for vscode, put your extended LD_LIBRARY_PATH in the wrapper

Open vscode with the wrapper -> done.

This worked like a charm!

truatpasteurdotfr · 2021-06-23T08:48:24Z

the same electon excuse has been raised for teams end of support on centos7...

iostrym · 2021-06-23T09:23:48Z

affected by this issue, let me tell you what I did:

* Download a recent gcc-tarball from a GNU mirror + compile

* Take the content of x86_64-pc-linux-gnu/libstdc++-v3/src/.libs and copy to a dir of your choice (eg. ~/lib64/libstdc++-v3)

* Write a start wrapper for vscode, put your extended LD_LIBRARY_PATH in the wrapper

* Open vscode with the wrapper -> done.

this is the workaround to have 1.53 working without CPU problem, right ?

could you provide a zip of the package that we need to place in LD_LIBRARY_PATH + example of wrapper for vscode ? because i'm not familiar with this :/

arthurspa · 2021-06-23T11:39:32Z

affected by this issue, let me tell you what I did:
* Download a recent gcc-tarball from a GNU mirror + compile

* Take the content of x86_64-pc-linux-gnu/libstdc++-v3/src/.libs and copy to a dir of your choice (eg. ~/lib64/libstdc++-v3)

* Write a start wrapper for vscode, put your extended LD_LIBRARY_PATH in the wrapper

* Open vscode with the wrapper -> done.
this is the workaround to have 1.53 working without CPU problem, right ?

could you provide a zip of the package that we need to place in LD_LIBRARY_PATH + example of wrapper for vscode ? because i'm not familiar with this :/

I had the library already in my work environment, so I didn't need to download. I just exported the variable before running VSCode, e.g:

export LD_LIBRARY_PATH=/app/vbuild/RHEL7-x86_64/gcc/10.2.0/lib64/:$LD_LIBRARY_PATH
code ~/project_folder/

And this worked. I think you'd have to compile for your own environment. Here is where you can find the source code: http://ftp.gnu.org/gnu/gcc/gcc-10.2.0/

kurt-cb · 2021-07-01T18:33:47Z

IMHO, the correct solution to this problem is to provide a version of vscode that runs on centos 7 native. This can easily be done using the softwarecollections project (www.softwarecollections.org).

I was able to build the vscode open source using DevToolset-10 C++ compiler toolchain. This allows it to run native on centos-7
This is the docker file I used, and is on docker hub at kurtgo/vscode-centos7.

Devtoolset-10 is allows the entire thing to be built with compatible with centos7, using the latest gcc compiler.

Steps I used:

docker run -it -v /vsbuild:/home/kurtgo/vsbuild kurtgo/vscode-centos7 bash
# #git pull latest cpython, configure --prefix /user;make -j8 install
# cd /vsbuild;git clone  [email protected]:microsoft/vscode.git;cd vscode
# yarn
# yarn run gulp vscode-linux-x64
# cd ..
# tar cjf centos7-vscode.tar.bz2 vscode-linux-x64

Dockerfile I used to get dependencies:

from centos:7

run yum -y install curl; \
    curl -sL https://rpm.nodesource.com/setup_14.x | bash - ; \
    curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | tee /etc/yum.repos.d/yarn.repo; \
    rpm --import https://dl.yarnpkg.com/rpm/pubkey.gpg; \
    yum install -y yarn git zlib zlib-devel

run yum -y groupinstall "Development Tools"; \
    yum -y install libxkb*; \
    yum -y install libsecret-devel; \
    yum -y install libX11-devel.x86_64


run yum -y install centos-release-scl; \
    yum -y install devtoolset-10

run yum -y install libssl-devel zlib1g-devel libncurses5-devel \
  libncursesw5-devel libreadline-devel libsqlite3-devel libgdbm-devel \
  libdb5.3-devel libbz2-devel libexpat1-devel liblzma-devel libffi-devel
copy .bashrc /root/.bashrc

run yum -y install ncurses-devel openssl-devel readline-devel sqlite-devel

keegandent · 2021-07-01T19:00:57Z

IMHO, the correct solution to this problem is to provide a version of vscode that runs on centos 7 native. This can easily be done using the softwarecollections project (www.softwarecollections.org).

I was able to build the vscode open source using DevToolset-10 C++ compiler toolchain. This allows it to run native on centos-7
This is the docker file I used, and is on docker hub at kurtgo/vscode-centos7.

Devtoolset-10 is allows the entire thing to be built with compatible with centos7, using the latest gcc compiler.

I would suggest Devtoolset-7 considering the Ubuntu 18.04 CI they are treating as the primary linux target is GCC 7.4, but yes I absolutely agree that having an additional build route to maintain compatibility for Enterprise Linux 7 is not a big ask.

kvnlmr · 2021-07-20T14:30:17Z

We have a n easy workaround on our side with:

CentOS Linux release 7.9.2009 (Core)
Visual Studio Code 1.58.2

Instead of installing it with yum package manager, we install it through snapcraft.io

First, install Snap on CentOS:

sudo yum install epel-release -y
sudo yum install snapd -y
sudo systemctl enable --now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap

And then, install Visual Studio Code through Snap:

sudo snap install code --classic

mati-o · 2021-08-10T09:10:41Z

/verified

I am more than happy to confirm that 1.60.0-insider version works on CentOS 7! Many thanks!

iostrym · 2021-08-20T07:40:03Z

thanks. just to be sure, now we must also wait that stable version of vscode will get the correction. right ?

tazerdev · 2021-08-20T14:11:21Z

Apologies that I missed the update. I won't be able to verify until Monday, but it's sufficient for me that others have been able to do so. I'll chime in once I am able to confirm.

tazerdev · 2021-08-23T10:30:23Z

/verified

Thanks for fixing this issue.

sskamesh · 2021-09-13T11:32:31Z

/verified

working now with 1.60

fixes microsoft#115784

github-actions bot added the new release label Feb 4, 2021

isidorn assigned Tyriar Feb 5, 2021

gjsjohnmurray mentioned this issue Feb 5, 2021

VSCode requires CXXABI 1.3.9 which is not available in CentOS 7 #115851

Closed

gjsjohnmurray mentioned this issue Feb 5, 2021

"CXABI_1.3.9 not found" in 1.53.0 (CentOS 7) #115871

Closed

Tyriar closed this as completed Feb 5, 2021

Tyriar added the *question Issue represents a question, should be posted to StackOverflow (VS Code) label Feb 5, 2021

Tyriar reopened this Feb 5, 2021

Tyriar assigned deepak1556 Feb 5, 2021

Tyriar added bug Issue identified by VS Code Team member as probable bug linux Issues with VS Code on Linux and removed *question Issue represents a question, should be posted to StackOverflow (VS Code) labels Feb 5, 2021

deepak1556 added the candidate Issue identified as probable candidate for fixing in the next release label Feb 5, 2021

deepak1556 added this to the January 2021 Recovery milestone Feb 5, 2021

deepak1556 removed the candidate Issue identified as probable candidate for fixing in the next release label Feb 5, 2021

deepak1556 modified the milestones: January 2021 Recovery, February 2021 Feb 5, 2021

gjsjohnmurray mentioned this issue Feb 8, 2021

version 1.53 consumes 100% CPU on Linux #116092

Closed

deepak1556 mentioned this issue Jun 21, 2021

VSCode 1.57 hangs on linux with a message "Select a language to get started. Start typing to dismiss, or don't show this again." #126489

Closed

deepak1556 mentioned this issue Jun 23, 2021

install fails to create directory in /run/user/7413 #126313

Closed

This was referenced Jul 11, 2021

Iteration Plan for July 2021 #128444

Closed

Jupyter: Iteration Plan for July 2021 microsoft/vscode-jupyter#6628

Closed

rockdreamer mentioned this issue Jul 14, 2021

Use VSCode from unofficial flatpak NO_JIRA ccdc-opensource/ansible-role-ccdc-cpp-gui-dev-tools#2

Closed

Tyriar removed their assignment Jul 22, 2021

gjsjohnmurray mentioned this issue Jul 24, 2021

Vscode does not work after installed on CentOs 7. #129303

Closed

deepak1556 mentioned this issue Jul 25, 2021

fix: CXXABI requirements for older distros #129360

Merged

deepak1556 modified the milestones: July 2021, August 2021 Jul 25, 2021

deepak1556 closed this as completed in #129360 Aug 6, 2021

kieferrm mentioned this issue Aug 8, 2021

Iteration Plan for August 2021 #130368

Closed

91 tasks

deepak1556 added the author-verification-requested Issues potentially verifiable by issue author label Aug 9, 2021

deepak1556 added verified Verification succeeded and removed author-verification-requested Issues potentially verifiable by issue author labels Aug 10, 2021

jspraul mentioned this issue Sep 6, 2021

Failed to connect to the remote extension host server due to unsupported, out of date libraries like glibc (e.g. older CentOS version) microsoft/vscode-remote-release#103

Closed

github-actions bot locked and limited conversation to collaborators Sep 20, 2021

lemanschik pushed a commit to code-oss-dev/code that referenced this issue Nov 25, 2022

rpm-spec: fix the wrong claim about working on EL7

97d7968

fixes microsoft#115784

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update rpm dependencies file for newer CXXABI requirement #115784

Update rpm dependencies file for newer CXXABI requirement #115784

tazerdev commented Feb 4, 2021

vscodebot bot commented Feb 4, 2021

gjsjohnmurray commented Feb 4, 2021

gjsjohnmurray commented Feb 4, 2021

dcourtois commented Feb 5, 2021

tazerdev commented Feb 5, 2021

gjsjohnmurray commented Feb 5, 2021

RudiFueller commented Feb 5, 2021

Tyriar commented Feb 5, 2021

tazerdev commented Feb 5, 2021

Tyriar commented Feb 5, 2021

hardik-singhal commented Feb 6, 2021

elulcao commented Feb 6, 2021

markusdd commented Feb 8, 2021

arthurspa commented Jun 22, 2021

truatpasteurdotfr commented Jun 23, 2021

iostrym commented Jun 23, 2021

arthurspa commented Jun 23, 2021 •

edited

Loading

kurt-cb commented Jul 1, 2021 •

edited

Loading

keegandent commented Jul 1, 2021

kvnlmr commented Jul 20, 2021

mati-o commented Aug 10, 2021

iostrym commented Aug 20, 2021

tazerdev commented Aug 20, 2021

tazerdev commented Aug 23, 2021

sskamesh commented Sep 13, 2021

Update rpm dependencies file for newer CXXABI requirement #115784

Update rpm dependencies file for newer CXXABI requirement #115784

Comments

tazerdev commented Feb 4, 2021

vscodebot bot commented Feb 4, 2021

gjsjohnmurray commented Feb 4, 2021

gjsjohnmurray commented Feb 4, 2021

dcourtois commented Feb 5, 2021

tazerdev commented Feb 5, 2021

gjsjohnmurray commented Feb 5, 2021

RudiFueller commented Feb 5, 2021

Tyriar commented Feb 5, 2021

tazerdev commented Feb 5, 2021

Tyriar commented Feb 5, 2021

hardik-singhal commented Feb 6, 2021

elulcao commented Feb 6, 2021

markusdd commented Feb 8, 2021

arthurspa commented Jun 22, 2021

truatpasteurdotfr commented Jun 23, 2021

iostrym commented Jun 23, 2021

arthurspa commented Jun 23, 2021 • edited Loading

kurt-cb commented Jul 1, 2021 • edited Loading

keegandent commented Jul 1, 2021

kvnlmr commented Jul 20, 2021

mati-o commented Aug 10, 2021

iostrym commented Aug 20, 2021

tazerdev commented Aug 20, 2021

tazerdev commented Aug 23, 2021

sskamesh commented Sep 13, 2021

arthurspa commented Jun 23, 2021 •

edited

Loading

kurt-cb commented Jul 1, 2021 •

edited

Loading