Users can accidentaly install non-functional Codium due missing dependency information on older enterprise distributions e.g.CentOS7

[Sinihopea]

Updating into the latest Codium RPM will leave program in partially non-functional state due changed CXXABI requirements in upstream. These dependencies haven't been properly specified in the RPM .spec file and so doing e.g. "yum upgrade" will suddenly cause Codium to have some major unexpected issues. I just encountered this problem yesterday having updated my workstation.

RHEL7 and CentOS7 do not and will not offer the newer CXXABI newer Codium requires. This stems from upstream change in VSCode itself where they moved to Electron Framework 11 which has a dependency to newer C++ libraries. The lack of these newer libraries leads to for example non-functional terminal within Codium and several extensions breaking.

Their changelog notice about this: https://code.visualstudio.com/updates/v1_53#_electron-11-update

Upstream has had several issues about this which are closed because it's "won't fix" issue. Only thing users can do is to upgrade into newer C++ toolchain or downgrade the editor itself. For example some of these threads:

• Update rpm dependencies file for newer CXXABI requirement microsoft/vscode#115784
• VSCode requires CXXABI 1.3.9 which is not available in CentOS 7 microsoft/vscode#115851
• "CXABI_1.3.9 not found" in 1.53.0 (CentOS 7) microsoft/vscode#115871

I downgraded and added lock into Codium and things work now. I fully understand and do not expect Codium to receive any longer updates which will work on CentOS7. However it would be nice if you could add into RPM .spec file that Codium now requires this specific level of CXXABI to fully function.

Like mentioned by this user: microsoft/vscode#115784 (comment)

Thank you.

[daiyam]

Can you do a PR?

[Sinihopea]

Eh? No. I'm an end-user of Codium who stumbled into this issue. I don't know if they've updated the RPM .spec in VSCode upstream. I mostly just wanted to bring this bug to your attention because current Codium "el7" package isn't actually compatible with el7 because of this dependency problem. Without beforehand information about this issue users who update Codium to latest version will break their editor in el7 distros such as CentOS7.

[paulcarroty]

The workaround

VSCode (and VSCcodium too) now use Electron 11 & Ubuntu 18.04, so old distros will get problems sooner or later. Solution: upgrade to new OS release or use/create the backports.

[Sinihopea]

The workaround

VSCode (and VSCcodium too) now use Electron 11 & Ubuntu 18.04, so old distros will get problems sooner or later. Solution: upgrade to new release or use/create the backports.

You probably didn't read what I wrote. I don't mind using old version of Codium. What I am concerned is that suddenly out of blue my editor broke one morning because somewhere, somebody, pushed a button and released new EL7 Codium package into software repository which wasn't actually EL7 compatible. Fix is very simply just adding something like (I don't precisely know the format):

Requires: libstdc++.so.6(CXXABI_1.3.9)

...into the RPM .spec file which is used to build the Codium package. Package manager then knows it cannot install this into the system just straight. But because of poorly defined dependencies this non EL7 compatible package can just flow straight through when updating the system.

Furthermore that suggested "workaround" wouldn't be an acceptable solution if I cared about staying on the latest version of Codium. What that person suggested is compiling and installing a rogue out-of-package-system install of GCC and it's libraries into OS to be used only with the Codium. There are better solutions for this kind of fix such as AppImage, Flatpak, etc.

The whole point of Enterprise Linux Platform is that it provides and delivers a stability and continuity which won't be broken during its lifecycle. Since VSCode (Codium) need to break it, they should stop releasing updates which claim to be EL7 and not release a broken update that won't work on EL7 platform. And that's fully understandable. It's natural cycle of things since EL7 is nearing end of its life.

Also yes, the real solution is upgrading to a newer EL8 platform. However there are tons of software out there which still need to be maintained for customers running EL7 whom aren't willing to invest into upgrade yet.

[paulcarroty]

What I am concerned is that suddenly out of blue my editor broke one morning because somewhere

This commit switched the VSCodium build agent to Bionic. As you can see, Centos 7 image isn't even around. The .spec you're talking about used only for compressing compiled binaries to rpm.

The main problem - Centos 7 doesn't provide CXXABI_1.3.9 'cause his GCC is too old. It's why upgrading to v9 and recompiling works.

[Sinihopea]

The main problem - Centos 7 doesn't provide CXXABI_1.3.9 'cause his GCC is too old. It's why upgrading to v9 and recompiling works.

No, the main problem is that a package marked as EL7 compatible, isn't EL7 compatible. In this case Codium and Code. There is no RHEL7, CentOS7, Scientific Linux 7, Oracle Linux 7, etc. which ships with GCC 5.1 or newer which would have the CXXABI_1.3.9. EL7 is based around GCC 4.8.x and it is not going to change.

https://access.redhat.com/solutions/19458

In my opinion there are few options here, such as either the .spec is adjusted and non-compatible RPM packages drop the claim that they're EL7, or switch to EL8 base, or adjust dependencies so that it's again el7 compatible (which isn't going to happen according to Code devs). The fact that it's repackaged is not the point. I don't quite follow what you're trying to say.

[paulcarroty]

No, the main problem is that a package marked as EL7 compatible

Do you have any proof of Centos 7 (RHEL 7, OL7 etc) compatibility or this is your own fantasy?

[daiyam]

@paulcarroty In vscodium/vscode/resources/linux/rpm/code.spec.template, the line 3 is Release: @@RELEASE@@.el7.

[paulcarroty]

Centos 7 isn't supported by Electron anymore:

• Rendering issues wth Electron 11 electron/electron#27480 (comment)
• https://code.visualstudio.com/updates/v1_53#_electron-11-update

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

[daiyam]

Then maybe we should make a patch so the line 3 became Release: @@RELEASE@@.el8? Will it be ok?

[paulcarroty]

@daiyam yes, absolutely.

[paulcarroty]

@GitMensch can you add the list to #649?

[daiyam]

I've done the PR #660 with the mentioned change.

[GitMensch]

@paulcarroty wrote

@GitMensch can you add the list to #649?

No because it got merged in the meantime. If @stripedpajamas wants that I'll create a new PR adding this as a sub-item (I did not do this myself because the list is never complete giving the number of distros...

... and shouldn't CentOS7 still work when using the AppImage?

[paulcarroty]

and shouldn't CentOS7 still work when using the AppImage?

Rendering issues, and VSC contributor suggests to use remote development flow on Centos 7. So it will be completely broken sooner or later.

Since CentOS 7 is no longer on the supported distro in upstream, I don't think its worth spending time to narrow down a minimal repro.

[Sinihopea]

Then maybe we should make a patch so the line 3 became Release: @@RELEASE@@.el8? Will it be ok?

Yes, thank you. And while you're at it, please add Requires: libstdc++.so.6(CXXABI_1.3.9) so that package managers like yum, dnf, zypper, etc. can tell what this package requires to run at minimum as well and resolve the dependencies on their own. And in the case of CentOS7 and EL7 distributions in-general block the install process since EL7 distros do not support that newer ABI. This is why this issue exists.