Update rpm dependencies file for newer CXXABI requirement

[tazerdev]

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

[GitMensch]

You can follow the steps on this stackoverflow.com to build GCC 10.0.1

thanks but those were posted multiple times already - this is quite a big hack (it is even out of scope for "workaround") and if you cannot use yum install because you cannot install anything then you'd need to also build all the dependencies on your own before. Multiple hours work(aroundhack) and build time just to create a glibc library that works around a bug in vscode publishing)...

Don't get me wrong, I'd totally like CentOS7 to be supported (in this case that likely would happen with a different rpm repo where vscode+included glibc is found and the main repo version having the broken dependency claim fixed [which #117994 is about]) - but without a commitment of the vscode team I don't see that coming...

[markusdd]

The whole point is: Most people dicussing here are probably insiders in a sense that they have found this workaround already or they maintain some sort of devlopment infrastructure for multiple people. Such a hack is nice locally, but when you have whole teams working on their machines and multiple servers, such stuff gets messy real quick.

So I ask again: Is there a way for an official EL7 repo which has a dependency packages with a known good, CI-tested libstdc++? Is the VS code maintainer team willing to pursue that?

[LucienMP]

thanks but those were posted multiple times already ...

I am leaving this ugly hack here for the years ahead and because nobody listed the exact steps needed since there will likely be those that follow without the requisite skills or in future the version that will work with least hassle.

Like @appurist above my group rolls out CentOS7 for our device support, it costs millions for the device and so LTS is important, and we dont easily upgrade our customers, or ourselves.

Don't get me wrong, I'd totally like CentOS7 to be supported

Same here, this is one of the worst issues with Linux distro fragmentation, so I guess were stuck with 1.52.

Update: Additional comment based on @GitMensch below; it is a packaging issue but what I meant by fragmentation is that it ends up with difficulty supporting so many OS. And I also agree it doesn't excuse the poor handling of package requirements / phasing out of RHEL7/CENTOS7

[GitMensch]

this is one of the worst issues with Linux distro fragmentation

I don't think it is reasonable to complain about GNU/Linux distros because Microsoft commits something with a broken rpm spec to CentOS repos (explicit telling "I'm running fine with EL7 and I don't have s special CXXABI requirement either" when it does not).

This part is a packaging issue, which is a question about "does the packager cares". And if the packager cares it is also the question of the maintainers to decide if they want to support an nearly 4+ years left LTS system (knowing that they likely get a bunch of issues about "xyz does not work on CentOS7" [see closed issues about some, many of those point here] which then need to be fixed) or not. If the answer to the second one is "no" (which is a strategic decision by the repo owner which is named "microsoft" as would be a "yes") and the package cares, then the only thing he can to is applying changes like #117994 and republish the broken 1.53 versions.

[qwertycody]

+1 - Impacting many managed development environments internally

[appurist]

Thanks @LucienMP for posting the custom build steps for the dependency upgrades, which are shorter than what I've seen elsewhere. I'm running through them as a test on my development machine now (build does take a long time) but it has all worked so far (except there's a typo on the unzip, where -zcf should read -zxf). I think it is good to document clearly any steps that may be workarounds at some installations.

This won't be appropriate for my coworkers, but it good in general to know how to upgrade these dependencies, so I'm giving it a spin.

VS Code devs:

• Consider rolling back the change in 1.53, since the reason provided (to build an Electron 11 version of Code) is not actually required to do so.
• Also just because the negative impact on enterprise developers is almost overwhelming, and switching to supporting a short-lived distro (CentOS 8) with 9 months of life left, over a LTS enterprise distro (CentOS 7) makes little sense and may mean we're going to need to go through this again in less than a year.
• It violates the good engineering practice of building on your primary target system, to maximize effective testing and early detection of problems. The custom build + LD_ variable kludge significantly alters the system from the target production environment, masking the early discovery of potential problems.

Me:

• I'll speak to stakeholders about choosing an alternate LTS distro for production. I don't think they'll go for this, as it's a government/military environment that is standardized wider than my project, and quite slow to change. Clearly CentOS 8 is not appropriate either, given its short support life, but perhaps I could encourage RHEL8 or some other LTS distro be selected.

[appurist]

FYI, the instructions for running a newer code with the steps from @LucienMP do seem to work successfully for me. I was able to run a recent 1.55-insiders version with the LD_PRELOAD variable set. It's an ugly hack that doesn't allow you to just run code normally, takes over an hour to build, and I don't think I can suggest it to coworkers, but it does allow upgrades to Code on any machine where it's done, and gets a single developer past a show-stopper problem.

[GitMensch]

If you want to you can just copy the generated libraries to another system which is similar enough (as long as you don't change the architecture, but likely most of these centos/RHEL7 will be AMD64 in any case). This removes the need to build it over and over again (and you can also find out if a single shared object is enough to copy). ... and that also would be the option outlined above to package code along this library in a separate repo (or even always, works as long as -R can be used during linking, which likely is the case for RPM builds).

[sifordtj]

FYI, the instructions for running a newer code with the steps from @LucienMP do seem to work successfully for me. I was able to run a recent 1.55-insiders version with the LD_PRELOAD variable set. It's an ugly hack that doesn't allow you to just run code normally, takes over an hour to build, and I don't think I can suggest it to coworkers, but it does allow upgrades to Code on any machine where it's done, and gets a single developer past a show-stopper problem.

For you, yes. For others like me, no. I meticulously followed the steps and its a no-go. It produces the primary Makefile just fine (build/Makefile). But when actually building, it doesn't succeed. I tried with different versions (fresh each time) too - no luck. I'm not a linux expert by any means but I know my way around pretty good. The best that I can tell is that when issuing the make, there aren't makefiles in the necessary directories (e.g. build/fixincludes/Makefile, etc).

[LucienMP]

@sifordtj mentioned he couldnt get it going

... no-go ...

You maybe missing other packages, quite likely - always a nightmare with these things. If you want we can try to get something more robust.

What error did you get? You can get some more information as below, and also try putting your whole compile output into a log?

[lmurray]$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.9.2009 (Core)
Release:    7.9.2009
Codename:   Core

[lmurray]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) 

[nfstern]

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

Thank you for posting this, it helped me work around the issue.

[tilleyc]

Just adding on here - it's completely unprofessional to release a breaking change for a major distro, acknowledge it, and then tell people to pound sand. Maybe that flies with Windows software, but with repositories being what they are for Linux, you absolutely need to own and actively manage your packaging.

Please either commit to an official fix, or remove all versions above 1.52 from el7 availability.

[tazerdev]

One side effect that limits the usefulness of staying on 1.52 is that as plugins are updated they increasingly become incompatible. For instance, Microsoft's Python/Jupyter plugins no longer work but instead fail with the below message:

Cannot activate the 'Python' extension because it depends on the
'Jupyter' extension, which is not loaded. Would you like to reload the
window to load the extension?

But the Jupyter extension is active and loaded, and when you reload the window the same error comes up along with:

Sorry, something went wrong activating IntelliCode support
for Python. Please check the "Python" and "VS IntelliCode"
output windows for details.

Whereas everything worked after I first opened this issue, extensions are slowly beginning to become incompatible. As it is, python development in VS Code is effectively dead on RHEL7.

It may be worth opening up another issue, but I feel strongly that VS Code shouldn't allow incompatible plugins to be installed.

Also, It should be stated clearly and openly that VS Code and its official Microsoft plugins aren't versioned and that the project will only support the very latest version of the operating systems on which it claims to be compatible. Which means as soon as RHEL9 is released, you should plan for VS Code to breakdown and stop working shortly thereafter and with little notice.

And while I may not agree with that kind of development cycle (I certainly can't complain about free software and VS Code has been a wonderful piece of software for me for years), at least knowing up front that a development tool will only be functional for part of my operating system's life cycle will inform me enough to choose a different piece of software and to avoid recommending it to others.

Edit: I should clarify that while maintaining a separate repositories for Enterprise Linux versions (e.g., el7, el8) was initially my main concern, I feel it's no longer necessary without plugin compatibility enforcement. The fact is that even if you install the latest RPM that's truly compatible with el7 (i.e., no stdc++ issues), VS Code is still non-functional for the majority of tasks you'd hope to use it for.

[GitMensch]

I feel it's no longer necessary without plugin compatibility enforcement

Note: You can use old versions (download via the ms market place or, if you have that enabled (which is the default) and internet access working from vscode, directly from the extensions view (under the gear wheel). If they "once worked" they will work in the future, too.

But definitely: vscode check a plugin for compatibility before installing it (which needs an attribute that extension authors do have to provide), maybe only the jupiter plugin is broken in this case?

[tazerdev]

Thanks for the information @GitMensch. That's definitely a potential work around to extend the life of 1.52.x under RHEL7.

On a whim I did work through the process of getting the latest VSC to run in a podman container using the official RHEL8 Universal Base Image (registry.access.redhat.com/ubi8/ubi). Interestingly it exhibited the bug you referenced above (unresponsive right after start up.)

Since the container has ~/.vscode and ~/.config/Code directories mapped to my existing directories I suspected there's something corrupt in there. When I start with those directories empty, that problem disappears. Not a deal breaker for me as I just needs to copy some settings over.

Installing extensions and customizing settings seems to work when starting fresh. The only weird issues I've seen with this setup is:

1. libX11-xcb wasn't installed as a dependency. It's possible this is missing in the RPM spec file for RHEL8 but hasn't come up yet because it's almost always installed on desktop systems.
2. VS Code freezes when I try to resize the terminal window.
3. The detailed extension documentation doesn't render after selecting an extension on the explorer bar.

None of those are critical to my workflow. If this remains stable this will be my preferred work around until I upgrade to rhel8 as I don't have to rebuild glibc/libstdc++ and maintain them. To avoid clutter in this thread, my notes on this process are located at:

https://github.com/tazerdev/vscode-podman

I'll just need to disable updates and rebuild the container whenever an update is released.

[dx-coding]

I've had luck getting 1.54.3 running on RHEL7 by downloading libstdcxx-ng from anaconda, and just copying the library (lib/* from the tar) to /usr/share/code/.

I make no guarantees that this doesn't break anything

[toddpfaff]

Here's a solution that worked for me ...

• install ghettoforge repo for CentOS 7

  yum --nogpg install https://mirror.ghettoforge.org/distributions/gf/gf-release-latest.gf.el7.noarch.rpm

• install gcc10-libstdc++.x86_64

  yum install gcc10-libstdc++.x86_64

• create link to new libstdc++ where VSCode will find it at runtime

  ln -s /opt/gcc-10.2.1/usr/lib64/libstdc++.so.6 /usr/share/code/

• run code

  code

[outjoker]

@toddpfaff the steps that you mentioned for centos7, i followed similar steps for my rhel 7.9 workstation after which the vscode is not frozen anymore. kindly let me know if we need to do any other extra configuration for rhel 7.9 variant

thanks in advance.

[gjsjohnmurray]

@deepak1556 is the upcoming 1.56 also going to install on RHEL 7 / CentOS 7 and then not work properly there? If so, I guess I'm not understanding something about what can or can't be done in the packaging to prevent this.

[sifordtj]

Here's a solution that worked for me ... yum --nogpg install https://mirror.ghettoforge.org/distributions/gf/gf-release-latest.gf.el7.noarch.rpm yum install gcc10-libstdc++.x86_64 ln -s /opt/gcc-10.2.1/usr/lib64/libstdc++.so.6 /usr/share/code/ code

Thank you toddpfaff! This worked perfectly (except I had to add the requisite sudo in front). Finally an easy solution to a horrible problem.

[GitMensch]

is the upcoming 1.56 also going to install on RHEL 7 / CentOS 7 and then not work properly there? If so, I guess I'm not understanding something about what can or can't be done in the packaging to prevent this.

Hm, we changed the code.spec.template but obviously that template is later (possibly) used to create the final spec file which is then used to create the RPM - Where is that done (and does it actually use the current template)?

[J-M0]

@GitMensch, just changing the name of the RPM isn't enough. You could add libstdc++.so.6(CXXABI_1.3.9) to resources/linux/rpm/dependencies.json to make sure users on EL7 can't install VS Code, but that will make for an ugly error message when users try to update:

Resolving Dependencies
--> Running transaction check
---> Package code-1.56.0.x86_64 1620166346.el8 will be updated
---> Package code-1.56.0.x86_64 1620166346.el8 will be an update
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9) for package: code-1.56.0-1620166346.el8.x86_64
--> Finished Dependency Resolution
Error: Package: code-1.56.0-1620166346.el8.x86_64
           Requires: libstdc++.so.6(CXXABI_1.3.9)
**********************************************************************
yum can be configured to try to resolve such errors by temporarily enabling
disabled repos and searching for missing dependencies.
To enable this functionality please set 'notify_only=0' in /etc/yum/pluginconf.d/search-disabled-repos.conf
**********************************************************************

Error: Package: code-1.56.0-1620166346.el8.x86_64
           Requires: libstdc++.so.6(CXXABI_1.3.9)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

A better thing to do would be to reorganize the physical layout of the repository at packages.microsoft.com. Take a look at how the Extra Packages for Enterprise Linux does it: https://mirror.us-midwest-1.nexcess.net/epel/

Each supported distro is in its own directory containing directories matching the supported arches. This allows them to use a simple .repo file for all supported platforms by leveraging variables provided by yum and dnf. Microsoft doesn't have to do exactly like EPEL does, but can do a simple layout like this would work:

packages.microsoft.com/yumrepos/vscode
|-- 7
|   |-- code-1.52.1-1608136323.el7.armv7hl.rpm
|   |-- code-1.52.1-1608136411.el7.aarch64.rpm
|   |-- code-1.52.1-1608137084.el7.x86_64.rpm
|   `-- repodata
|       |-- 0a69337359d057c65faaec062e594b62bb43932164b9bca4ecf96690c550f0fe-filelists.xml.gz
|       |-- 1f302bfb2001c1ef9d6c40e7c1059b8a73441a9ba2fae673136d107811695262-primary.sqlite.bz2
|       |-- 3e4e5817d5cfe92ce866fa07b7d6ed417d1f998182a4289fae3fd2e7025563aa-other.xml.gz
|       |-- 816219971e8ec457d8b4eb984795e9b1bd67d44dd6cea1c685a9e8b30eaeb26e-filelists.sqlite.bz2
|       |-- abe814ff6a989cf06f477a04ca15583340294f7124f3d15dd39cb8ba19b63a14-other.sqlite.bz2
|       |-- b602426435977020abda77e7289e12c7b8ef9a38e9b99ac934c595a105371fa8-primary.xml.gz
|       `-- repomd.xml
`-- 8
    |-- code-1.56.0-1620166175.el8.aarch64.rpm
    |-- code-1.56.0-1620166250.el8.armv7hl.rpm
    |-- code-1.56.0-1620166346.el8.x86_64.rpm
    `-- repodata
        |-- 453f7766cf3481baa5d5b81841dc083bf65645ce3eff15fafe6daabef0a63878-other.xml.gz
        |-- 46796e57cea3353b87dee2845ba6062b24049181887de04811f2ca599f33ae34-primary.sqlite.bz2
        |-- 6a7ea7e7f614d0e6ecb6cdc0faf3ca0bee8c17c24f1f9bf23803a7ebf11e60d8-filelists.xml.gz
        |-- 8df55284c130e7b0a7af16ddf6533ca41f7c65252fe9d6e0a3fbc889dc08272e-primary.xml.gz
        |-- 9c7e3782270a6b6cb6ebb08b02198c568d573500d436e7ee955bfbc354e3093a-other.sqlite.bz2
        |-- bf68f018a8949c4a8555d6efbab35458857addb38fb373bdde2a967556c7ca45-filelists.sqlite.bz2
        `-- repomd.xml

then MS needs to tell people what to put in /etc/yum.repos.d/vscode.repo, 7 for people on Enterprise Linux 7 and 8 for people on Enterprise Linux 8 and Fedora >= 22:

[code]
name=Visual Studio Code
baseurl=https://packages.microsoft.com/yumrepos/vscode/**<7 or 8>**
enabled=1
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc

This allows for two good things:

1. If MS wanted to keep supporting VS Code on EL7, they could include a libstdc++ package in the 7 repo that would be used by VS Code to keep working
2. When this inevitably happens again, users will silently stop receiving updates rather than have broken software automatically installed on their machines.

---

Finally, the best idea of all might actually be to use the existing fedora, rhel, and centos directories on packages.microsoft.com. Those are already set up more or less like standard multi-distro repos.

[fncambres]

Aquí hay una solución que funcionó para mí ...

• instalar ghettoforge repo para CentOS 7

yum --nogpg install https://mirror.ghettoforge.org/distributions/gf/gf-release-latest.gf.el7.noarch.rpm

• instalar gcc10-libstdc ++. x86_64

yum install gcc10-libstdc++.x86_64

• crear un enlace a la nueva libstdc ++ donde VSCode lo encontrará en tiempo de ejecución

 ln -s /opt/gcc-10.2.1/usr/lib64/libstdc++.so.6 /usr/share/code/

• Ejecutar código

code

Gracias me funciono

[OlafRocket]

There are a couple of valid suggestions to keep the Centos 7 compatibility, is Microsoft going to comment on this? Centos 7 is still supported at least until June 30, 2024 and is still widely used. for example in the VFX industry.

[SonGokussj4]

Hi. I'm IT at our company so on my DEV machine I've added mirror.ghettoforge.org/... and installed gcc10-libstdc++ lib and it's working just fine. But I can't do that for all of our users. (no approved installation of "unknown sources" which ghettoforge is)

We're using shared linux path where I've unpacked newest code and it broke everything for all users. Any thought how to do this for all users in our network? Or we have to stay on the 1.53 version...?

Code is on shared drive: /SHARED/apps/vscode... (with /SHARED/apps/bin linking ../vscode/code) That is mounted /SHARED -> /sharedapps/... Each user has extended PATH for /sharedapps/bin Once a time I just refresh the vscode folder from newest tar.gz.

[GitMensch]

Any thought how to do this for all users in our network?

Using the ghettoforge approach brings you a local libstdc++, instead of the link just copy it to the shared vscode folder, then run ldd on that to check if there are more libraries you need to copy.

Or we have to stay on the 1.53 version...?

I'd personally likely stay with 1.53 until there's an official MS-Repo that solves this, @J-M0 outlined the solution... or try to switch to Theia (at least check if it works with older libstdc++).

[tawani]

Here's a solution that worked for me ...

• install ghettoforge repo for CentOS 7

yum --nogpg install https://mirror.ghettoforge.org/distributions/gf/gf-release-latest.gf.el7.noarch.rpm

• install gcc10-libstdc++.x86_64

yum install gcc10-libstdc++.x86_64

• create link to new libstdc++ where VSCode will find it at runtime

 ln -s /opt/gcc-10.2.1/usr/lib64/libstdc++.so.6 /usr/share/code/

• run code

Also worked on CentOS 8

[keegandent]

Was this not a consideration when the motion to upgrade to Electron 11 was being evaluated? RHEL 8 just turned two years old; RHEL 7 is hardly a legacy OS, and I'd struggle to think of any features compelling enough to drop support for it. I understand there's a presumption that "dev machines aren't servers" and should be more up to date, but in a corporate environment where everything is configured uniformly against a STIG, this is not always the case.

[iostrym]

Hello, thanks for all feedback, its sad that on website it is not clearly indicated that RH7 is no longer supported.

Better solution is then to install 1.53 version (2021/01) that is last version that officially support RH7, right ?

About the workaround (gcc10-libstdc++.x86_64 installation), I don't have internet access from our server. Is it possible to install gcc10-libstdc++.x86_64 directly from an RPM downloaded from a website ? or is there a lot of depedency ? there will be no conflict between gcc10-libstdc++.x86_64 and already installed RH7 packages ?

do you know if there are plan to make a new version that will keep compatibility with RH7 ?

[sifordtj]

I (and others) would appreciate an official explanation as to why CentOS 7 is not supported when it has a much longer EOL (End Of Life) than CentOS 8. Most larger enterprise organizations will continue running CentOS 7 ... not CentOS 8. Support for CentOS 8 expires this year whereas support for CentOS 7 will continue until June of 2024 (https://wiki.centos.org/About/Product).

Can we get an official answer on this? Because it literally makes no sense.

[J-M0]

@iostrym, the Ghetto Forge libstdc++ doesn't have any dependencies, so you should easily be able to install the rpm on its own. It installs into /opt so it shouldn't conflict with anything already on the system.

Direct link: https://mirror.ghettoforge.org/distributions/gf/el/7/gf/x86_64/gcc10-libstdc++-10.2.1-7.gf.el7.x86_64.rpm

[GitMensch]

I (and others) would appreciate an official explanation as to why CentOS 7 is not supported when it has a much longer EOL (End Of Life) than CentOS 8.

Simply because "upstream Electron": https://code.visualstudio.com/updates/v1_53#_electron-11-update

Also see the note above from @Tyriar:

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 [#115784 (comment)](https://github.com/microsoft/vscode/issues/115784#issuecomment-774087742), 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

So the question is not "why". The open question is: will MS provide special RPMs as outlined by @J-M0 at https://github.com/microsoft/vscode/issues/115784#issuecomment-834835385 (which would possible lead to additional bug reports because upstream Electron dropped the support and therefore newer Electron versions may only work if patched) - and yes: I'd personally appreciate that...

[sifordtj]

I (and others) would appreciate an official explanation as to why CentOS 7 is not supported when it has a much longer EOL (End Of Life) than CentOS 8.

Simply because "upstream Electron": https://code.visualstudio.com/updates/v1_53#_electron-11-update

I don't expect you to know/see that everything that you have provided I already know. So many posters in this thread. I've even already done the workaround and everything is aok (for now).

I guess I worded my question wrong. Maybe it was better written as "I (and others) would appreciate an official explanation as to why the upstream Electron was considered to be more important than keeping inline with an actual supported operating system (CentOS 7) as opposed to a soon to be unsupported operating system (CentOS 8)."

[GitMensch]

I see, then this is a question for another repo - see https://github.com/electron/electron/issues/27480 (and others) that write about "not on the supported list any more".

[appurist]

@GitMensch Except that those comments are actually the part that doesn't make sense.

I develop Electron 11 and 12 versions of my app on my CentOS 7 target machine and nothing broke compatibility in Electron updates so as far as I can see there's nothing inherent in the Electron updates that require this change. This whole "we had to bump our build image to use Ubuntu-18.04 for x64 linux machines to consume Electron" sounds to me like they just decided to update their OS and noticed things broke and said "$@^#, I guess it's a breaking change." That comment you linked to is actually the part that needs explaining because it doesn't make sense. They broke compatibility for the current LTS version of a major Linux distribution without even blocking automatic updates on that distribution, rendering countless development machines non-functional. In secure environments, it's not possible to just add another lib repo as a "workaround". In some cases, I'm going to need a federal government (military) bureaucrats, working from home due to COVID, to upgrade the laptop they provided, or to bless another library repo.

[iostrym]

@iostrym, the Ghetto Forge libstdc++ doesn't have any dependencies, so you should easily be able to install the rpm on its own. It installs into /opt so it shouldn't conflict with anything already on the system.

Direct link: https://mirror.ghettoforge.org/distributions/gf/el/7/gf/x86_64/gcc10-libstdc++-10.2.1-7.gf.el7.x86_64.rpm

thanks a lot. do we have a feedback for this workaround from people that use massively all function of this tool ? are we well confident about this workaround "working" ?

[GitMensch]

@appurist It may be that MS answers referencing Electron and the Electron answers are not "because it doesn't work", but "because we don't care", I don't know. I only can note what I've seen, for example in https://github.com/electron/electron/commit/f61dedb7e5babef35f3aa81d71646c2983d08b6e - and hope that in the future neither "breaking environments" nor "not support current EOL-environment" will happen for vscode - like anyone else.

[appurist]

@GitMensch Agreed. I'm not sure what the problem is here since my Electron 11 & 12 apps, and all the others I use, continued to run fine, but only VS Code didn't. I think this means CentOS 7 could be added to that list in the link, yet for some reason VS Code still requires something newer. Perhaps the problem is that VS Code's 18.04 build machine isn't a generic 18.04 but has its libraries upgraded, adding additional dependencies beyond those if it was just building on 18.04. Or something like that. All I know is that it isn't a problem with the Electron binaries as stated.

[tilleyc]

@GitMensch Perhaps the problem is that VS Code's 18.04 build machine isn't a generic 18.04 but has its libraries upgraded, adding additional dependencies beyond those if it was just building on 18.04. Or something like that. All I know is that it isn't a problem with the Electron binaries as stated.

This is it exactly, but they either don't want to admit it, or are unwilling to do so. It's a very easy fix (change to older libs [read: a different build machine] for building the el7 rpms), but in true MS fashion, that's asking too much, so we're all being served flimsy excuses.

I have plenty more I could say, but it's all rather unkind, so I'd rather just leave it at the facts of:

• this should be a relatively easy fix
• it requires core Linux knowledge to fix, which seems to be lacking
• Devs are unable or unwilling to do so and instead want to point fingers and serve excuses

Very poor showing. VScode on Linux is going to see usage plummet, and it deserves to.

[keegandent]

@appurist I am in a somewhat similar boat, we are about to try manually compiling and injecting the updated libstdc++.so.6 from the GCC that ships with ubuntu 18.04 to see if that fixes it, but I’m more concerned with what might break going forward.

I was doing this to try and get us away from Eclipse (yes, please kill me) but now I don’t see this becoming the primary editing tool if it’s not even supported for EL7.

It doesn’t bother me that they aren’t supporting a real fix for this, either in VSCode itself or submitting a PR to Electron. What burns my ass is that I know if these changes had broken Windows 7 compatibility they wouldn’t have made it into so much as the betas, despite being 5 years older.

[deepak1556]

Thanks @GitMensch and others for helping with the workarounds.

First let me clarify on the toolchain update, when we updated to Electron 11 the v8 headers that come with it were no longer compilable with gcc < 5, these headers are used by native node modules which we bundle. At that time, our build ci was based on ubuntu-14.04, I considered it to be a good time to align vscode ci with same versions electron builds and tests against. Hence today's ci is based on ubuntu-18.04, you can find the config at https://github.com/microsoft/vscode-linux-build-agent/tree/main/bionic-x64

Second, with respect to supported linux versions by Electron. https://github.com/electron/electron/blob/master/docs/tutorial/support.md#linux only specifies the versions that are tested, that does not mean Electron will not work on other versions, it infers issues from outside the list will not be prioritized. Also if chromium runtime works on a particular distro then Electron should work for the most part, and if an application bundles some native component via plugin then the supported distro versions might further dial down. This leads to my final point and the core of this issue.

Most of the native addon that we bundle now requires a higher CXXABI due to the v8 version but it was missed to update the rpm dependency which is what this issue is originally about and it should be fixed. Thanks @J-M0 for the descriptive solution, will give it a try but the earliest I will get to addressing this issue is in July iteration, I am happy to accept PRs in the meantime if anyone wants to help.

[keegandent]

@deepak1556 Thanks for the clarification, but can you specify which headers? Also is it that they only need a newer compiler version, or is it that they actually use features available only in >=CXXABI_1.3.9? Because if it’s the former, the binaries can likely be fixed (made to work with earlier ABI) with a change to how they are generated. Typically you can use a devtoolset on an older system to use a newer compiler but keep the binaries compatible.

If it’s the latter, maybe we can create a PR in Electron or even v8 to increase the compatibility of those headers and backport the fix to earlier Electron and Code versions.

[appurist]

@deepak1556 Okay, if I followed that, it's not an incompatibility with newer Electron versions (which is why I don't see any issue building under CentOS 7 with new Electrons) as much as it's a problem with the fact that VS Code has some native modules that compile against the V8 headers that you get from Electron and those V8 headers correspond to an updated V8 now included in newer Electrons? And those headers V8 now assume a newer GCC than was used previously.

Is there no way to specify a different Electron version when building the native modules? Or different headers themselves? VS Code would run fine on CentOS 7 without the updated GCC, the dependency on the newer CXXABI is not a runtime one but it seems it is a build-time (headers) problem that results in a new runtime dependency. and it's just that by using the newer GCC it's breaking the current latest CentOS LTS, something that will be unavoidably used at many enterprise sites for years to come.

This is enough of a problem for us that we're going to need to reevaluate whether we can still use VS Code at all. Until now, VS Code has been a hands-down favorite and "just works", but with this problem we have a showstopper that means we may need to code with WebStorm or ATOM or good code editors with command-line builds and browser debugging. I really don't want to do that. I love VS Code. But this change, especially during a "minor" 1.53 update, has cost the whole team days of effort just to track down, and cap it at the last working version, as a temporary workaround that won't be permitted longer than a few more weeks. I've been praising Microsoft's major contributions to open source and Linux for some time now, and a lot of that good will gained is going out the window as I start hearing "I told you so". I know it's a pain to resolve, but if you need to do a specific RHEL7/CentOS7 build or something, or build the native modules separately with older headers and tools, or some other workaround like that, it is 100 times better than pushing this ripple out to all your users in a breaking minor update.

[deepak1556]

but can you specify which headers?

https://source.chromium.org/chromium/chromium/src/+/main:v8/include/ and some nodejs public api headers, these will get used via api abstraction library https://github.com/nodejs/nan or https://github.com/nodejs/node-addon-api (which is also ABI stable) depending on what the native module chose to use.

Also is it that they only need a newer compiler version, or is it that they actually use features available only in >=CXXABI_1.3.9?

Don't remember, have to compile these modules on the older distro to confirm. Will get back on this.

Typically you can use a devtoolset on an older system to use a newer compiler but keep the binaries compatible.

Yup that would help depending on the result of previous question, but I would like to keep vscode ci distro aligned with what Electron uses for its testing. And this is what Electron currently uses https://github.com/electron/build-images/blob/master/Dockerfile . So it is best if we can come with a solution that does not require using older distro.

Is there no way to specify a different Electron version when building the native modules? Or different headers themselves

Nope, but if the modules were built with https://github.com/nodejs/node-addon-api then it might be possible to use different headers.

I know it's a pain to resolve, but if you need to do a specific RHEL7/CentOS7 build or something, or build the native modules separately with older headers and tools, or some other workaround like that, it is 100 times better than pushing this ripple out to all your users in a breaking minor update.

I understand the frustration caused by this breakage and this issue is kept open to resolve it in a way similar issues don't happen in upcoming electron updates. So the fix will take some time but we will get there.

[iostrym]

hello, I don't understand because I retrograde 1.56 version to 1.53 version because it is said here to be the last version compatible with redhat 7. but recently I discover high CPU usage on 1.53 version for red hat 7 (100% CPU without doing anything in the tool). this is documented here : https://github.com/microsoft/vscode/issues/116092 and this ticket is said to be a dupplicate of this current ticket. Then my question is the following : what is the version to be used with red hat 7.9 ? 1.52 version ? sure ?

do I correctly understood that vs code will be corrected this summer to be compatible with red hat 7 ?

[arthurspa]

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]

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

[iostrym]

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]

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]

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  git@github.com: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