search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.89k stars 28.75k forks source link

Update rpm dependencies file for newer CXXABI requirement #115784

Closed tazerdev closed 3 years ago

tazerdev commented 3 years ago

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
vscodebot[bot] commented 3 years ago

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

gjsjohnmurray commented 3 years ago

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

gjsjohnmurray commented 3 years ago

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

dcourtois commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Tyriar commented 3 years ago

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

tazerdev commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

dcourtois commented 3 years ago

Hi, I just wanted to let other users of CentOS/RHEL7 that the method suggested by @RudiFueller works fine (at least for him and me) As for me, I couldn't find prebuilt packages of recent Gcc so I built one from scratch:

  1. Go to https://gcc.gnu.org/mirrors.html, choose a mirror, and download a recent Gcc (I used the 5.5.0)
  2. Unpack and build using something like: 
    installdir=/path/to/some/directory
./configure ./configure --prefix=$installdir CFLAGS="-O3 -g0" CXXFLAGS="-O3 -g0" LDFLAGS="-s" --disable-multilib
make -j10
make install
  3. Create a code.sh script or something, set the executable flag (chmod +x code.sh) and put this inside: 
    export LD_LIBRARY_PATH=/path/to/some/directory/lib64:$LD_LIBRARY_PATH
/usr/bin/code

You will probably need to install a few dev libraries to build Gcc. Eventhough I'm a developer, my CentOS was still missing a few: sudo yum install gmp-devel mpfr-devel libmpc-devel

VSCode seems to work fine like this.

markusdd commented 3 years ago

So I can also confirm we went a similar route and deployed a newer gcc version in a seperate path via our internal rpm repo and came up with a similar wrapper script.

I nevertheless would suggest that this should also be part of the test suite for VS Code, meaning:

1) Provide this workarounf in the docs 2) Have such an environment run in the regression for vscode to ensure stuff does not break over and over again 3) make a recommendation which gcc/addtll. libs to use.

Maybe there is also a way to provide a script repo or something that automates some of this stuff for users which are not as confident in compiling and deploying a whole new gcc by themselves.

gjsjohnmurray commented 3 years ago

In #116126 a RHEL7 user is reporting that the 'Report Issue' option from the Help menu broke with 1.53. Any RHEL7/CentOS7 users here willing to check that? Whether or not it's broken for you, please also say whether or not you've done the above workaround already.

dcourtois commented 3 years ago

@gjsjohnmurray I've tested the Report Issue on CentOS 7 and: works fine with the workaround, doesn't work at all without the workaround.

deepak1556 commented 3 years ago

First of all sorry about this drop in support! There are two parts to the problem with support for RHEL7, CentOS7

1) They have not been officially listed as supported platforms by electron for a long time now https://www.electronjs.org/docs/tutorial/support#supported-platforms . What this means is that, we are on our known if any issues related to the runtime were to be found.

2) Update to electron 11 required us to update our build image which caused the regression to use newer CXXABI and the above workaround to use newer gcc toolchain should resolve it as also mentioned in the release notes https://code.visualstudio.com/updates/v1_53#_electron-11-update and this should resolve the issues related to dialog boxes not popping up or high cpu usage.

Even after fixing the above error there were reports of rendering issues which was discovered in our insiders testing https://github.com/electron/electron/issues/27480 , the issue was side-effect of refactor from chromium to use xcb instead of xlib for the display server communication. We currently don't have the scope to investigate this issue further.

With that said, we are happy to accept any PR that adds the workaround for fixing the CXXABI error to the docs, but we can't list the above versions of distro as officially supported by vscode.

andrecp commented 3 years ago

I understand the challenges but just want to flag that this caused massive pain to a lot of users that are in an older version of CentOS (usually enterprise...), it seems reasonable to me as a workaround to not have the new RPM be installed by default on CentOS-7 since it doesn't work at all. And then in the docs have the workaround if you want to install a more up-to-date version by building your own GCC and pointing to it.

omenos commented 3 years ago

I've been able to successfully build a natively functioning OSS version of VSCode on CentOS 7 (after basic testing like checking the terminal and extension installation). No separate workaround side-load-libs to manage. Steps below:

# Prep work (as root or with sudo)
> yum -y install centos-release-scl epel-release
> yum -y install rh-nodejs10 devtoolset-9 make libX11-devel libxkbfile-devel libsecret-devel fakeroot git
> scl enable rh-nodejs10 "npm install --global yarn"

# Build
> scl enable rh-nodejs10 devtoolset-9 bash
> git clone -b 1.53.0 --depth 1 https://github.com/microsoft/vscode.git
> cd vscode
> yarn --frozen-lockfile --network-timeout 180000
# Potentially optional
> yarn npm-run-all --max_old_space_size=4095 -lp compile "electron x64" playwright-install download-builtin-extensions
# End optional
> yarn run gulp vscode-linux-x64-min
> yarn run gulp vscode-linux-x64-build-rpm

Your RPM will now be available in .build/linux/rpm/x86_64/code-oss-<VERSION>.rpm. You can either extract the contents with rpm2cpio <RPM> | cpio -idm and do what you want (like a central install), or install it directly.

A note, however: The Code OSS build does not support the Extensions Marketplace out of the box. You will need to add the following blob to the resources/app/product.json to enable it (extensions can still be installed through VSIX directly without it, though):

    "extensionsGallery": {
        "serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
        "cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
        "itemUrl": "https://marketplace.visualstudio.com/items",
        "controlUrl": "https://az764295.vo.msecnd.net/extensions/marketplace.json",
        "recommendationsUrl": "https://az764295.vo.msecnd.net/extensions/workspaceRecommendations.json.gz"
    },

I don't know if the proposed change to the RPM SPEC file will negatively impact this process in the future. The devtoolset here will statically link in the symbols needed directly into the code binary, which would normally be available at runtime in libstdc++ from a GCC 5+ package. In this case I'm using GCC 9 as it's the latest DTS available.

deepak1556 commented 3 years ago

it seems reasonable to me as a workaround to not have the new RPM be installed by default on CentOS-7 since it doesn't work at all. And then in the docs have the workaround if you want to install a more up-to-date version by building your own GCC and pointing to it.

@andrecp yup that is the next set of actions to be done here.

rkd628 commented 3 years ago

Ubuntu 14.04 also has that issue..

IgorNovozhilov commented 3 years ago

There is still a way to solve the problem with dependencies on older OS. You can use an alternative package manager snapcraft.io. (installing-snap-on-centos) In the sandbox, everything works fine, depending on the operating system. I'm use CentOS-7 and VSCode in snap, and everything works fine for me. Use it: https://snapcraft.io/code

PS: Or use a different package manager, for example Flatpak: app Visual Studio Code

sreerajkksd commented 3 years ago

Compiling gcc along with the libraries and setting LD_LIBRARY_PATH solution worked for me.

This is the detailed set of steps:

Create a build directory. This directory is temporarily only. (Make sure that you have around 4GB space left here)

mkdir gcc-9.3.0-build

Move to the build directory

cd gcc-9.3.0-build

Configure GCC first. (this is part of the gcc build procedure)

../gcc-9.3.0/configure --prefix=$install_dir --enable-languages=c,c++ --disable-multilib

Finally build gcc

make -j$(nproc) && make install

- Create a wrapper script for running vscode

!/usr/bin/bash

exec env LD_LIBRARY_PATH=/directory/to/install/lib64:$LD_LIBRARY_PATH /usr/bin/code

Luisss commented 3 years ago

While waiting for a fix, a downgrade makes vscode functional again. yum downgrade code.x86_64 In my case, I had to downgrade two times.

eustaqxchange commented 3 years ago

Compiling gcc along with the libraries and setting LD_LIBRARY_PATH solution worked for me.

This is the detailed set of steps:

  • Install the required libraries for building the packages
yum install -y gmp-devel mpfr-devel libmpc-devel
  • Get the gcc archives
curl https://ftp.gnu.org/gnu/gcc/gcc-9.3.0/gcc-9.3.0.tar.gz -O
tar xvf gcc-9.3.0.tar.gz
  • Build the package
install_dir=/directory/to/install/
mkdir gcc-9.3.0-build
cd gcc-9.3.0-build
../gcc-9.3.0/configure --prefix=$install_dir  --enable-languages=c,c++ --disable-multilib
make -j$(nproc) && make install
  • Create a wrapper script for running vscode
#!/usr/bin/bash
exec env LD_LIBRARY_PATH=/directory/to/install/lib64:$LD_LIBRARY_PATH /usr/bin/code

Can you elaborate the steps 3 and 4 should I copy paste this to notepad? Maybe upload a video tutorial. Thanks.

denizobi commented 3 years ago

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)).

mintyc commented 3 years ago

Centos 7 workaround assuming vscode repo is available sudo yum remove code sudo yum install code-1.51.1 (and set updates to None in vscode)

Note this picks up (and rolls back) any extensions already set in the newer version sominimal reconfiguration required

israelKusayev commented 3 years ago

This answer should help! (I had the same issue on centOS 7, but now I'm able to run the latest version of vscode without any problems) https://github.com/cdr/code-server/issues/347#issuecomment-482670081

andre-rosa commented 3 years ago

An AppImage should be provided.

sreerajkksd commented 3 years ago

Compiling gcc along with the libraries and setting LD_LIBRARY_PATH solution worked for me. This is the detailed set of steps:

  • Install the required libraries for building the packages
yum install -y gmp-devel mpfr-devel libmpc-devel
  • Get the gcc archives
curl https://ftp.gnu.org/gnu/gcc/gcc-9.3.0/gcc-9.3.0.tar.gz -O
tar xvf gcc-9.3.0.tar.gz
  • Build the package
install_dir=/directory/to/install/
mkdir gcc-9.3.0-build
cd gcc-9.3.0-build
../gcc-9.3.0/configure --prefix=$install_dir  --enable-languages=c,c++ --disable-multilib
make -j$(nproc) && make install
  • Create a wrapper script for running vscode
#!/usr/bin/bash
exec env LD_LIBRARY_PATH=/directory/to/install/lib64:$LD_LIBRARY_PATH /usr/bin/code

Can you elaborate the steps 3 and 4 should I copy paste this to notepad? Maybe upload a video tutorial. Thanks.

I self documented the steps 3 and 4.

robdmorton commented 3 years ago

I can't change my gcc version due to project constraints.

Is there a solution coming in which centos7 users don't have to change their environment to accommodate VSCode?

...and yes, I already reverted back to v1.52.1 for the interim.

jfgudk commented 3 years ago

Running downgrade 3 times resolved it for me.


[~]$ sudo yum downgrade code.x86_64
...
Resolving Dependencies
--> Running transaction check
---> Package code.x86_64 0:1.52.1-1608137084.el7 will be a downgrade
---> Package code.x86_64 0:1.53.0-1612368438.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved
...

Removed:
  code.x86_64 0:1.53.0-1612368438.el7                                                                                                                                                                              

Installed:
  code.x86_64 0:1.52.1-1608137084.el7                                                                                                                                                                              

Complete!
cameronkerrnz commented 3 years ago

I was planning to rebuild my development VM, but can't afford to do that mid-sprint. The following will downgrade in a single-step to the previous version (that I was using).

sudo yum downgrade code-1.52.1-1608137084.el7.x86_64

I'm on CentOS 7 because I do a lot of Ansible development currently, and some of those actions are local actions.

A potentially better way for VSCode users to avoid introducing binding constraints between project environments and workstation environments would be to use VSCode Dev Containers... particularly great if you're doing anything with the likes of JRuby (recent headache) but even then that can end up with some leaky abstractions (eg. If you're Docker Desktop environment is using WSL2, last time I looked (which was prior to last significant update of WSL2), Ansible was behaving inconsistently.

GitMensch commented 3 years ago

As @Tyriar has said that the intermediate fix of not bringing breaking updates I've created a PR to do this (it actually just changes one byte...).

But as long as 1.53 RPMs are in the repos this likely does not help much - these would have either be removed or republished with the correct minimal version.

Concerning the possible "mid-term-solutions": Is it considered/planned to package or statically link libcstd++ in a future version to work around this issue?

Comments to suggestions found in this thread:

I definitely recommend to NOT replace libstdc++ to an unsupported version in the system path (suggestion at linked cdr/code-server issue) as this potentially breaks the complete system. I can recommend having a single system library in a different place (self-build or possibly even from an external app that ships it) pre-loaded with LD_PRE_LOAD in a wrapper (I had to do something similar to get code running via X11 forwarding) - that only effects one single application.

I also agree that an AppImage would be a nice thing to publish, but that was declined for vscode in https://github.com/microsoft/vscode/issues/10857#issuecomment-552500236.

markusdd commented 3 years ago

I think it should be no problem to offer a seperate 'compat' rpm/deb package that can be installed alongside that puts a fitting libstdc++ into the right path and carries the main package as a dependency and vice versa.

This would solve all the headaches and saves users from having to tinker themselves.

GitMensch commented 3 years ago

Nice idea but this won't work because the compat EL7 rpm cannot depend on the soon EL8 main rpm (and it would have to overwrite the final binaries). @markusdd Despite of this: can you check for a GLIBXX-only rpm (which does NOT overwrite the system libstdc++)? If that's available then people can yum install it and only need the LD_PRELOAD,

markusdd commented 3 years ago

why not setup a seperate EL7 repo?

As it's a very, and I mean VERY, popular Distribution I do not see why this wouldn't make sense. Builds are automated, so where's the problem?

sifordtj commented 3 years ago

I am baffled about how this decision could have possibly been made. CentOS 8 has an end of life of December of 2021. CentOS 7's end of life is in June of 2024. For this reason, many organizations are opting to keep CentOS 7 and not update to CentOS 8. It would have made much more sense to find a way to keep updates for VS Code working on CentOS 7 than to pick a supported OS that has an End of Life in less than a year. This is crazy.

s2terminal commented 3 years ago

When I wanted to run $ yum update before this issue was resolved, it worked to put the following in /etc/yum.conf

exclude=code

It will no longer update the VS Code when $ yum update is performed.

tazerdev commented 3 years ago

@s2terminal yum versionlock is a bit easier to work with and recommended by Red Hat for pinning versions. The better way is to disable or remove the yum repository from your system entirely because, as stated earlier in this thread, the el7 platform has been abandoned so there's no point in even looking for updates.

You'll then need to set the update policy for code to none in your settings:

"update.mode": "none"

For giggles I did update to the version that was released this morning and it doesn't work at all. In fact it froze with 100% cpu usage and had to be kill -9'd. While this isn't technically a bug, the packages are still being falsely marked as el7 which indicates compatibility with RHEL7.X. For instance:

code-1.54.2-1615424933.el7.x86_64.rpm

This would be akin to releasing 64 bit binaries but marking the packages i386. Again, I'm not requesting developers maintain compatibility but name the RPMs properly, and provide appropriate repositories, or people will rightly come away from a VS Code on RHEL7 install thinking this project is a disaster, which will negatively affect Microsoft's reputation.

GitMensch commented 3 years ago

And #117994 should fix the wrong claim... (maybe should include an explicit CXXABI, but I can't test for the version define so will leave that to others)

LucienMP commented 3 years ago

Also the docs page needs to be more extensive/updated to reflect EOL for CentOS7/RHEL7. ( https://code.visualstudio.com/docs/supporting/requirements )

Alternatively maybe it should reflect supported OS vs VSCode version so people can make the decision to use, and less confusion post install (as the install silently fails)

GitMensch commented 3 years ago

That's definitely a good point, it still lists RHEL7, but that actually don't work.

appurist commented 3 years ago

I am the technical team leader in an enterprise (government) environment where my development laptop is spec'd to match the target environment, which uses CentOS 7 for LTS stability (support extends to 2024, well beyond CentOS 8 which ends this year). My software will be installed on server boxes on Navy ships, and I need to develop on a Navy-supplied laptop running the same environment.

This sudden -- and as far as I can see unannounced -- nuclear bomb in our development toolchain is going to cost us tremendously, unless it can be rolled back quickly.

Somewhere between a 1.52 and 1.54 update, our primary development tooling was completely broken, without even an error message being displayed. I've already lost a lot of time reporting and diagnosing a sudden complete hang of VS Code after a "minor" upgrade, and don't really have good alternatives here now that I know what the problem is.

This sudden change to drop support for major LTS OS releases is highly unprofessional, and a shock on an otherwise wonderful history, with VS code setting an example for how development tools should be done. Until now. It is extremely disruptive to the community, and I hope the VS Code team will rethink it.

Management above me will see this as a clear sign that Microsoft should not be trusted with Linux development tools, and their commitment to support Linux. I suspect the VS Code team has no plans to drop support for Windows 7, 8, or 8.1, so dropping support for CentOS 7 and RHEL 7 stands out as ... inappropriate. I assume there is a cost-benefit trade-off forcing this change, but I want to make it clear that, given a working 1.52 on these operating systems, I cannot imagine a benefit for 1.54 that justifies this cost.

I can temporarily workaround this problem by pinning an old version, using one of the techniques mentioned above, but blocking all VS Code updates is probably not a smart or sustainable approach, especially in a government military environment where security is such an overwhelming priority.

I will need to report to them that I must now look at alternative tooling for our projects. I am not really looking forward to switching to WebStorm or ATOM or one of the alternatives. I've grown fond of Code and this is more than disappointing, and this will be seen by many as an "I told you so" moment, a betrayal of Linux developers by Microsoft. I know (or at least think) this isn't accurate, however I'm not going to be in a position to defend this decision.

sifordtj commented 3 years ago

I am the technical team leader in an enterprise (government) environment where my development laptop is spec'd to match the target environment, which uses CentOS 7 for LTS stability (support extends to 2024, well beyond CentOS 8 which ends this year). My software will be installed on server boxes on Navy ships, and I need to develop on a Navy-supplied laptop running the same environment.

This sudden -- and as far as I can see unannounced -- nuclear bomb in my development toolchain is going to cost us tremendously, unless it can be rolled back quickly.

Somewhere between a 1.52 and 1.54 update, our primary development tooling was completely broken, without even an error message being displayed. I've already lost a lot of time reporting and diagnosing a sudden complete hang of VS Code after an upgraded, and don't really have good alternatives here now that I know what the problem is.

This sudden change to drop support for major LTS OS releases is highly unprofessional, and a shock on an otherwise wonderful history, with VS code setting an example for how development tools should be done. Until now. It is extremely disruptive to the community, and I hope the VS Code team will rethink it.

Management above me will see this as a clear sign that Microsoft should not be trusted with Linux development tools, and their commitment to support Linux. I suspect the VS Code team has no plans to drop support for Windows 7, 8, or 8.1, so dropoing support for CentOS 7 and RHEL 7 stands out as ... inappropriate. I assume there is a cost-benefit trade-off forcing this change, but I want to make it clear that, given a working 1.52 on these operating systems, I cannot imagine a benefit for 1.54 that justifies this cost.

I can temporarily workaround this problem by pinning an old version, using one of the techniques mentioned above, but blocking all VS Code updates is probably not a smart or sustainable approach, especially in a government military environment where security is such an overwhelming priority.

I will need to report to them that I must now look at alternative tooling for our projects. I am not really looking forward to switching to WebStorm or ATOM or one of the alternatives. I've grown fond of Code and this is more than disappointing, and this will be seen by many as an "I told you so" moment, a betrayal of Linux developers by Microsoft. I know (or at least think) this isn't accurate, however I'm not going to be in a position to defend this decision.

I couldn't agree more (and said as much above). Once more and more people find this post, we will see more and more complaints. Like you, I'm doing government work. We're clearly not going to "upgrade" to CentOS 8 when it reaches its EOL in months compared to YEARS for CentOS 7. This is an absolutely huge blunder that needs to be rectified. You can't just remove CentOS 7 support when there is literally no other CentOS that has Long Term Support. It makes ZERO sense. None. And then to do it with just the tiniest footnote in the January release notes is unacceptable ... all while keeping the software available for auto-update (even though clearly the VSCode team already knows that they removed the ability for it to work on CentOS 7).

markusdd commented 3 years ago

I also do not understand why there isn't a pragmatic solution.

Make a EL7-specific repo, package a fitting libstc++ alongside vscode as dependency, done.

No hacked start-scripts, no wild out-of-path installations of compiler and libraries, no modified LD_LIBRARY_PATH.

I can understand why the developers had to make the switch, but I have to agree, abondoning the most widely used enterprise distirbution is very, very short-sighted. (especially without warning and announcement)

appurist commented 3 years ago

The January release notes claim:

Electron 11 update

In this milestone, we finished the exploration to bundle Electron 11 into VS Code, thanks to everyone involved with testing and self-hosting on insiders. This is a major Electron release and comes with Chromium 87.0.4280.141 and Node.js 12.18.3.

Breaking change

As a side effect of this update, we had to bump our build image to use Ubuntu-18.04 for x64 linux machines to consume Electron. This update raised the minimum GLIBCXX requirement to 3.4.22 for our native modules, which breaks support for older distros on desktop.

But my CentOS 7 app is an Electron 11.3 app. Builds and runs fine on CentOS 7 without any special steps. Not sure what "we had to" means here. Perhaps this is all a misunderstanding

@Tyriar what am I missing? This seems completely needless.

appurist commented 3 years ago

Specific steps for anyone else finding this problem and needing to pin VS Code to 1.52 in order to not have their toolchain completely disrupted:

sudo yum downgrade code-1.52.1-1608137084.el7.x86_6 or if you don't have it installed: sudo yum install code-1.52.1-1608137084.el7.x86_6

sudo yum install yum-plugin-versionlock (if it's not already installed) sudo yum versionlock code (to lock it at 1.52)

Note that it's still possible to test more recent versions alongside 1.52 by installing the nightly "insiders" build, which installs a separate code-insiders command.

[Thanks to @tazerdev for mentioning versionlock above, and all the extremely helpful comments by him and others here.]

LucienMP commented 3 years ago

You can lock your update to 1.52.1 as @appurist says in his comment CentOS7 Locking Code version

If you want to use VSCODE beyond 1.52.1 on CentOS7 you will need an updated libstdc++ as others have said, I dont recommend you update your O/S one but have a secondary one for use by vscode. This of course deals with launching code at current time of writing (2021/03/19) but doesnt guarantee that other extensions or features wont also require other libraries that become harder to side-load like this.

Option 1: Source it from somewhere else I found that Ghettoforge is hosting a GCC10.2.1 release that contains stdlibc++ AND is targeted at CentOS7, and you can download the rpm from there gcc10-libstdc++-10.2.1-7.gf.el7.x86_64.rpm

# Get the rpm
wget https://mirror.ghettoforge.org/distributions/gf/el/7/gf/x86_64/gcc10-libstdc++-10.2.1-7.gf.el7.x86_64.rpm

# Extract the RPM to non-root user folder output
mkdir output
cd output
rpm2cpio ../gcc10-libstdc++-10.2.1-7.gf.el7.x86_64.rpm | cpio  -idmv

# Run Code with a forced use of the stdlib
LD_PRELOAD=$(readlink -m ./opt/gcc-10.2.1/usr/lib64/libstdc++.so.6.0.28) code

Option 2: Build it yourself. You can follow the steps on this stackoverflow.com to build GCC 10.0.1 (no need to install) and use LD_LIBRARY_PATH/LD_PRELOAD to let vscode run in CentOS7 (7.8.2003 as per below article and on mine 7.9.2009)

StackOverflow Article

# required libraries: (some may already have been installed)
sudo yum install libmpc-devel mpfr-devel gmp-devel

# if dnf install libmpc-devel is not working try:
sudo yum install libmpc-devel

# install zlib
sudo yum install zlib-devel*

# Get Package
wget https://ftp.gnu.org/gnu/gcc/gcc-10.1.0/gcc-10.1.0.tar.gz

# Expand and Compile, expect about 6GB of used space
tar -zxf gcc-10.1.0.tar.gz
cd gcc-10.1.0
mkdir build
cd build
../configure --with-system-zlib --disable-multilib --enable-languages=c,c++

# this may take around an hour or more to finish (depending on your cpu speed)
make -j 8 

LD_PRELOAD=$(readlink -m ./x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.28)
code