Change:
VS Code Version: 1.53.0 OS: RHEL7.9 Error: The terminal process failed to launch: A native exception occurred during launch ( version CXXABI1.3.9' not found (required by )).
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: &lt;!-- score: 0.507 --- &lt;!-- score: 0.476 --- &lt;!-- score: 0.453 --- &lt;!-- score: 0.449 --&lt;!-- potentialduplicatescomment --
See Breaking Change section at
Better link
Same issue here. Unfortunately CentOS 7 is still wildly use in some areas, and the links pointed to by 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)
From the changelog: 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?
previous versions can be downloaded by going to 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?
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 x8664-pc-linux-gnu/libstdc++- and copy to a dir of your choice (eg. ~/lib64/libstdc++-v3) Write a start wrapper for vscode, put your extended LDLIBRARY_PATH in the wrapper Open vscode with the wrapper -done.
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 , 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
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.
good point, we need to update the deps in Historically I just pull in whatever Chromium targets in their spec.
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**
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.
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.
Hi, I just wanted to let other users of CentOS/RHEL7 that the method suggested by 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: to , choose a mirror, and download a recent Gcc (I used the 5.5.0) and build using something like: a script or something, set the executable flag () and put this inside: 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: VSCode seems to work fine like this.
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.
In 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.
I've tested the on CentOS 7 and: works fine with the workaround, doesn't work at all without the workaround.
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 . 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 and the above workaround to use newer gcc toolchain should resolve it as also mentioned in the release notes 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 , 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 error to the docs, but we can't list the above versions of distro as officially supported by vscode.
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.
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: Your RPM will now be available in . You can either extract the contents with 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 to enable it (extensions can still be installed through VSIX directly without it, though): 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 from a GCC 5+ package. In this case I'm using GCC 9 as it's the latest DTS available.
yup that is the next set of actions to be done here.
Ubuntu 14.04 also has that issue..
There is still a way to solve the problem with dependencies on older OS. You can use an alternative package manager . () 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:
Compiling gcc along with the libraries and setting LDLIBRARYPATH solution worked for me. This is the detailed set of steps: Install the required libraries for building the packagesGet the gcc archivesBuild latest gccCreate a wrapper script for running vscode
While waiting for a fix, a downgrade makes vscode functional again. In my case, I had to downgrade two times.
Can you elaborate the steps 3 and 4 should I copy paste this to notepad? Maybe upload a video tutorial. Thanks.
The terminal process failed to launch: A native exception occurred during launch ( versionCXXABI1.3.9' not found (required by )).
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
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)
An should be provided.
I self documented the steps 3 and 4.
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? yes, I already reverted back to v1.52.1 for the interim.
Running downgrade 3 times resolved it for me. [~]$ sudo yum downgrade code.x8664 ... Resolving Dependencies --Running transaction check ---Package code.x8664 0:1.52.1-.el7 will be a downgrade ---Package code.x8664 0:1.53.0-.el7 will be erased --Finished Dependency Resolution Dependencies Resolved ... Removed: code.x8664 0:1.53.0-.el7 Installed: code.x86_64 0:1.52.1-.el7 Complete!
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). 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.
As 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 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
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.
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). 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 it and only need the LD_PRELOAD,
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?
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.
When I wanted to run before this issue was resolved, it worked to put the following in It will no longer update the VS Code when is performed.
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: 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: 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.
And 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)
Also the docs page needs to be more extensive/updated to reflect EOL for CentOS7/RHEL7. ( ) 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)
That's definitely a good point, it still lists RHEL7, but that actually don't work.
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 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.
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).
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 LDLIBRARYPATH. 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)
The claim: 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 what am I missing? This seems completely needless.
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: or if you don't have it installed: (if it's not already installed) (to lock it at 1.52) Note that it's still possible to test more recent versions alongside 1.52 by installing the , which installs a separate command. [Thanks to for mentioning versionlock above, and all the extremely helpful comments by him and others here.]
You can lock your update to 1.52.1 as says in his comment 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 Option 2: Build it yourself. You can follow the steps on this to build GCC 10.0.1 (no need to install) and use LDLIBRARYPATH/LDPRELOAD to let vscode run in CentOS7 (7.8.2003 as per below article and on mine 7.9.2009)
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 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 is about]) - but without a commitment of the vscode team I don't see that coming...
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?
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 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. 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 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
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 and republish the broken 1.53 versions.
+1 - Impacting many managed development environments internally
Thanks 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 should read ). 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.
FYI, the instructions for running a newer code with do seem to work successfully for me. I was able to run a recent 1.55-insiders version with the LDPRELOAD 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.
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).
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).
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?
Thank you for posting this, it helped me work around the issue.
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.
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: But the Jupyter extension is active and loaded, and when you reload the window the same error comes up along with: 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.
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?
Thanks for the information 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 (). Interestingly it exhibited the bug you referenced above (unresponsive right after start up.) Since the container has and 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: 11-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. Code freezes when I try to resize the terminal window. 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: I'll just need to disable updates and rebuild the container whenever an update is released.
I've had luck getting 1.54.3 running on RHEL7 by downloading , and just copying the library (lib/* from the tar) to /usr/share/code/. I make no guarantees that this doesn't break anything
Here's a solution that worked for me ... install ghettoforge repo for CentOS 7install gcc10-libstdc++.x86_64create link to new libstdc++ where VSCode will find it at runtimerun code
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.
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.
Thank you toddpfaff! This worked perfectly (except I had to add the requisite sudo in front). Finally an easy solution to a horrible problem.
Hm, we changed the 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)?
just changing the name of the RPM isn't enough. You could add to 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: A better thing to do would be to reorganize the physical layout of the repository at Take a look at how the Extra Packages for Enterprise Linux does it: Each supported distro is in its own directory containing directories matching the supported arches. This allows them to use a simple file for all supported platforms by leveraging variables provided by and . Microsoft doesn't have to do exactly like EPEL does, but can do a simple layout like this would work: then MS needs to tell people what to put in , for people on Enterprise Linux 7 and for people on Enterprise Linux 8 and Fedora = 22: This allows for two good things: MS wanted to keep supporting VS Code on EL7, they could include a libstdc++ package in the repo that would be used by VS Code to keep working 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 , , and directories on Those are already set up more or less like standard multi-distro repos.
Gracias me funciono
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.
Hi. I'm IT at our company so on my DEV machine I've and installed 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: (with linking ) That is mounted Each user has extended PATH for Once a time I just refresh the vscode folder from newest
Using the ghettoforge approach brings you a local libstdc++, instead of the link just copy it to the shared vscode folder, then run on that to check if there are more libraries you need to copy. I'd personally likely stay with 1.53 until there's an official MS-Repo that solves this, ... or try to switch to Theia (at least check if it works with older libstdc++).
Also worked on CentOS 8
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.
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++.x8664 installation), I don't have internet access from our server. Is it possible to install gcc10-libstdc++.x8664 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 ?
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 (). Can we get an official answer on this? Because it literally makes no sense.
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 so it shouldn't conflict with anything already on the system. Direct link:
Simply because "upstream Electron": Also see the note above from So the question is not "why". The open question is: will MS provide special RPMs as outlined by at (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...
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)."
I see, then this is a question for another repo - see (and others) that write about "not on the supported list any more".
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.
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" ?
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 - and hope that in the future neither "breaking environments" nor "not support current EOL-environment" will happen for vscode - like anyone else.
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 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.
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.
I am in a somewhat similar boat, we are about to try manually compiling and injecting the updated 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.
Thanks 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 Second, with respect to supported linux versions by Electron. 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 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.
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.
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.
and some nodejs public api headers, these will get used via api abstraction library or (which is also ABI stable) depending on what the native module chose to use. Don't remember, have to compile these modules on the older distro to confirm. Will get back on this. 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 . So it is best if we can come with a solution that does not require using older distro. Nope, but if the modules were built with then it might be possible to use different headers. 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.
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 : 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 ? 52 version ? sure ? do I correctly understood that vs code will be corrected this summer to be compatible with red hat 7 ?
This worked like a charm!
the same electon excuse has been raised for teams end of support on centos7...
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 LDLIBRARY_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: And this worked. I think you'd have to compile for your own environment. Here is where you can find the source code:
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 (). 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: Dockerfile I used to get dependencies:
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.
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 First, install Snap on CentOS:  And then, install Visual Studio Code through Snap:
/verified I am more than happy to confirm that version works on CentOS 7! Many thanks!
thanks. just to be sure, now we must also wait that stable version of vscode will get the correction. right ?
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.
/verified Thanks for fixing this issue.
/verified working now with 1.60

Discussion:
Name:     @@NAME@@ Version:  @@VERSION@@ <del> Release:  @@RELEASE@@.el7 </del> <ins> Release:  @@RELEASE@@.el8 </ins> Summary:  Code editing. Redefined. Group:    Development/Tools Vendor:   Microsoft Corporation