Vscode-cpptools: GLIBC 2.18 dependency

[delmyers]

This was copied from the reviews on the extension page. Not sure if it is a language service issue, or a debugger issue.

[Ebiroll]

Maybe it is because of `GLIBC_2.18' dependency?

ldd bin/Microsoft.VSCode.CPP.Extension.linux
bin/Microsoft.VSCode.CPP.Extension.linux: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by bin/Microsoft.VSCode.CPP.Extension.linux)
linux-vdso.so.1 => (0x00007ffc5bb43000)

[pieandcakes]

I verified that the Debugger works on CentOS. @sridmad , I think this is a language service issue.

[bfarley792]

I'm using RHEL 7, but see the same thing. The debugger works as expected, but I don't have Go to Definition, etc. and .browse.VC.db never gets created. I also see the GLIBC_2.18 error with ldd on the extension (RHEL 7's GLIBC version is 2.17)

[desimonk]

Symbol searches or go to definition does not work at all. Language service is not working at all. I am using Centos 7.2 and latest version of VS Code downloaded today. Version of my glibc is 2.17 and I get same error as other user reported about glibc. If anyone worked around this issues please post it.

[desimonk]

I just saw that this issue is first opened on April 19, and there is no acknowledgement on this issue. I.e. NO HOPE of being resolved anytime soon. Will go back to eclipse. It is really shame that this is not tested on Centos 7 given it is announced on their website. This kind of false claims often wastes many people's time.

[delmyers]

@desimonk
I'm sorry to hear that you find our responses to be too slow. Unfortunately, sometimes some issues slip through the cracks as we continue to try to improve the product. We do want to get our extension to work on as many platforms as we can, so thank you for bringing this issue back to our attention.

@sridmad, @greazer: it looks like users are having issues because the language service is linked against glibc 2.18. Is it possible to use a lower version?

[mk3890]

Same story here. Preventing me from really using on RHEL7.2

[ampatel21]

For those that would like to run vscode-cpptools on CentOs/RHEL 7 while we wait for devs to address this issue.

1) Download Src/Build/Install glibc 2.18 onto your system. I got a source rpm from Fedora 20 for glibc-2.18. Make sure to change the install prefix for the library. I picked '/opt/glibc-2.18'. DO NOT FORGET TO CHANGE THE INSTALL PREFIX.

2) Create a bash script file called Microsoft.VSCode.CPP.Extension.linux.sh in "~/.vscode/extension/ms-vscode.cpptools-0.9.1/bin" with the following contents...

#!/bin/bash

/opt/glibc-2.18/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.18/lib:/lib64 ~/.vscode/extensions/ms-vscode.cpptools-0.9.1/bin/Microsoft.VSCode.CPP.Extension.linux

3) Modify "~/.vscode/extensions/ms-vscode.cpptools-0.9.1/out/src/LanguageServer/C_Cpp.js"

Change the following line from " extensionsProcessName += '.linux'; " to " extensionProcessName += '.linux.sh'; "

[Ebiroll]

Yes ampatel21 tip works on centos7. I did the following:
wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.xz
tar xvf glibc-2.18.tar.xz
cd glibc-2.18;mkdir build;cd build
../configure --prefix=/opt/glibc-2.18/
make -j
su
make install
Then follow ampatel21:s step 2&3 in previous post.

Version 0.9.2 still have not fixed this issue but also works with step2 and the following contents..
#!/bin/bash

/opt/glibc-2.18/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.18/lib:/lib64:/usr/local/lib64 ~/.vscode/extensions/ms-vscode.cpptools-0.9.2/bin/Microsoft.VSCode.CPP.Extension.linux

[ericgrossNI]

Thanks, this workaround worked for me on Scientific Linux 7.2 (still ships with Glibc 2.17 for some reason). The only thing missing from your steps is to make sure to chmod +x the new script.

[s-martin]

Thanks, the workaround works for CentOS 7.2. At least I finally get the lightbulb and "Add include path to settings" for my includes.
However, so far there was no .browse.VS.code created and go to definition doesn't work properly yet.

[Ebiroll]

With the 0.9.3 it seems that both GLIBC_2.18 & GLIBC_2.17 is required.
However if you want a workaround try this:

1. wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.xz
2. tar xvf glibc-2.18.tar.xz
3. cd glibc-2.18
4. mkdir build
5. cd build
6. ../configure --prefix=/opt/glibc-2.18
7. sudo make install
8. Create a bash script file called Microsoft.VSCode.CPP.Extension.linux.sh in "~/.vscode/extension/ms-vscode.cpptools-0.9.3/bin" with the following contents...

#!/bin/bash
    /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.18/lib:/lib64:/usr/local/lib64 ~/.vscode/extensions/ms-vscode.cpptools-0.9.3/bin/Microsoft.VSCode.CPP.Extension.linux  

1. chmod a+x Microsoft.VSCode.CPP.Extension.linux.sh
   You can try to start it on the comand line ./Microsoft.VSCode.CPP.Extension.linux.sh
   If it starts silently without errors, then you are fine, otherwise add missing dependencies to the --library-path option in the script,
   if not you will see something like this,

./Microsoft.VSCode.CPP.Extension.linux: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.18' not found (required by ./Microsoft.VSCode.CPP.Extension.linux)
./Microsoft.VSCode.CPP.Extension.linux: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by ./Microsoft.VSCode.CPP.Extension.linux)

1. Modify "~/.vscode/extensions/ms-vscode.cpptools-0.9.3/out/src/LanguageServer/client.js"
   Change the following line from " extensionProcessName += '.linux'; " to " extensionProcessName += '.linux.sh'; "

[s-martin]

Although the provided workarounds fix the issues, are there any plans to address the root cause of this issue?

The workarounds have to be redone every time the cpptools extension is updated.

[Ebiroll]

v 0.9.3 still not working under Centos, unless you use the workaround.
For just the Visual studio code ide you only need GLIBC_2.15
Why cannot this extension be compiled in a similar way?

[fradav]

I made a small script to automatize @Ebiroll 's answer
there
You may have to change the wrapper line and the vscode-oss to vscode, for example

[ianwestc]

So is the src.rpm available anywhere? I'd greatly prefer recompiling vscode for GLIBC 2.16 rather than roll my own newer version.

[rachellixie]

I can't get this working on my Ubuntu 12.04 LTS. I have glibc2.15. when I download glibc2.18, and do "../configure --prefix=/opt/glibc-2.18/", it gives me an error: * These critical programs are missing or too old: ld

anyone can help me? thanks.

[sean-mcmanus]

@rachellixie Ubuntu 12.04 LTS is no longer a "supported" distribution of Ubuntu. You should upgrade your OS (see https://en.wikipedia.org/wiki/Ubuntu_version_history ).

[rachellixie]

@sean-mcmanus thanks. I know it's not officially supported. but I can not upgrade now due to our project need. so I want to try the workaround here. is there a way?

[sean-mcmanus]

@rachellixie From our telemetry, out of the very small number of Ubuntu 12.0.4 users installing our extension, 0 of them were able to successfully use it, so unfortunately, a workaround might not be available.

[alanbirtles]

anyone got the workaround script to work with 0.12.2? the language server is launching but VS code doesn't seem to be able to use it

[sean-mcmanus]

@alanbirtles I'm not sure what script you're using, but we added a Microsoft.VSCode.CPP.IntelliSense.Msvc.[exe|darwin|linux] executable so maybe that needs to be added to your script too.

[alanbirtles]

I'm using the instructions posted above https://github.com/Microsoft/vscode-cpptools/issues/19#issuecomment-266168029

the language server is there but intellisense doesn't work, I had no issues using the same workaround in 0.12.1

[alanbirtles]

actually it does now seem to be mostly working

[dcourtois]

@alanbirtles Did you do something to make it work again ? I was also using the workaround without any problem until the last update :/

[alanbirtles]

no I'm not sure what if anything I did, the problem may have been that the script wasn't marked as executable? I think previous versions worked without an executable script but the new version doesn't?

[dcourtois]

Thanks for the answer. I works kind of randomly on my computer ... sometimes it works fine, and some other time, doesn't.

Issue moved to #989

[bobbrow]

@dcourtois, that looks like a bug. If you don't mind, I'm going to move the discussion for that to a new issue. #989

[dcourtois]

@bobbrow I don't mind at all. Next monday I'll try to get more informations and will try to post that on the issue. Thanks

[GabeAl]

Red Hat Enterprise Linux, CentOS, Scientific Linux, Ubuntu 12.04 (still installed on computer lab terminals in many places)... these are big names. All remain unsupported, so the many folks at school/work who want this nice lightweight editor for C/C++ are SOL.

This is not a reasonable requirement nor a reasonable workaround (it's neither "lightweight" nor future-proof). This should properly be addressed as a bug.

Solution without effort on your part? There exists the notion of "static compilation" of libraries that prove to be troublesome dependencies. Have you tried just linking it statically? Might work! :)

[GabeAl]

Additionally, the workaround posted above fails because the compilation of glibc fails on my system (gcc-6). Hoping for an official fix!

[sean-mcmanus]

@GabeAl We haven't figured out how to remove our dependency on the dynamic libraries -- simply using -static is insufficient (e.g. warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking). Our telemetry indicated only 3-4% of users were impacted by this, so investigating a fix has not been a priority for us.

[ericgrossNI]

@sean-mcmanus is the telemetry looking at active users or first launches? There are a lot of pretty big distros that are currently affected (seems like percentage-wise would be more than 3-4%), and I'd guess a lot of people try it once, find it doesn't work, and give up on Code and try something else.

I haven't dug into the vscode codebase, and I suspect that the CPP extension library is a closed binary anyway, but can you elaborate on the linking issue? I'd assume the easiest solution would be to link the CPP extension to a lower glibc version, or just make it link to glibc statically. If that library itself calls dlopen(), then I guess that would trigger the warning, but as long as the libraries that it also loads are either statically linked themselves or against a lower glibc version, it shouldn't be an issue and you should be able to safely suppress it.

[sean-mcmanus]

@ericgrossNI Installs by users. Most users use Ubuntu 14+ or something similar. If more people upvote this issue and/or take the survey (https://www.research.net/r/VBVV6C6 ) and say they want support for OS's with glibc < 2.18 then maybe we could investigate this more sooner.

We use cmake and when we supply the static linker flag, it still brings in "-export-dynamic -dynamic-linker -Bdynamic -lsupc++ -lgcc_s" even though none of those flags are explicitly specified, and our attempts to get rid of those give various errors (multiple definition errors, "dynamic STT_GNU_IFUNC symbol 'strcmp' with pointer equality in ".../libc.a" can not be used when making an executable", etc.).

We build on Ubuntu 14, so maybe building on Ubuntu 12 would be another fix, but our build machine would need to be changed.

[sergio-nsk]

@sean-mcmanus I suppose you should stop using TLS variables declared with the C++ thread_local keyword in Microsoft.VSCode.CPP.Extension.linux. This should remove dependency from __cxa_thread_atexit_impl introduced in glibc 2.18. This C++ dependency is the only from glibc 2.18.
More info about it you can read here Destructor support for thread_local variables

[sean-mcmanus]

@sergio-nsk Thanks for the info. I seem to recall some error involving __cxa_thread_atexit_impl. It looks like replacing thread_local with __thread on Linux would be sufficient in our case.

[sergio-nsk]

@sean-mcmanus The new update of IntelliSense is released two days ago. There are a lot of useful changes but unfortunately it still not working on CentOS 7. objdump -T informs about IntelliSense requiring GLIBC_2.18 __cxa_thread_atexit_impl, i.e. thread_local is not replaced with __thread yet.
Could you please inform us about your team further plans, when we can expect extra wanted updates?

[sean-mcmanus]

@sergio-nsk Our database client code doesn't compile with __thread because we use thread local variables with non-trivial destructors. I don't know when we'll be able to implement a workaround.

[sergio-nsk]

@sean-mcmanus It is not a hard task, although __thread is useless with non-trivial destructors. You may use pthread_key_create in each thread to create, initialize a thread specific objects and register required their destrutors. If the main thread uses a thread specific objects too, do not forget to call pthread_exit(exitCode) before main exits (direct call or register it in atexit).

[s-martin]

Is there any information available on a possible implementation date of this fix? It seems there may be enough users which are affected by this issue, when there was the release 14.2 to shut down the noise #1227 of these clients.

[s-martin]

Workaround described in https://github.com/Microsoft/vscode-cpptools/issues/19#issuecomment-266168029 still works, but now you have to edit the file /out/src/LanguageServer/client.js instead of C_Cpp.js

[bobbrow]

@s-martin, there were actually only about 40 machines affected. However, the effect on these machines was so severe that it warranted an emergency patch. Thanks for the reminder about the change in file name. I updated the comment above with the correct file name.

[bobbrow]

I'm sorry for your frustration, but you must not have noticed that I added this to the December 2017 milestone. Keep calm 👑 Support is coming! 😉

[s-martin]

@bobbrow Appreciate it! Thanks!

[sean-mcmanus]

We have an 0.14.4-insider release that works on CentOS7 (64-bit, not 32-bit): [link removed, this is fixed in mainline builds as of 0.14.4]. VS Code itself doesn't expose a way for extensions to publish "insider" releases, so you just need to download the .vsix and run the "Install from VSIX" command. If you hit bugs, please file a new issue (or upvote an existing one) and mention you're on 0.14.4-insider, and we might be able to fix the bugs before releasing the non-insider build. The release also fixes additional bugs listed in our December milestone: https://github.com/Microsoft/vscode-cpptools/milestone/7 , except for the 32-bit issue which we're still working on.

[dtrudg]

Confirm that the 0.14.4-insider is working nicely on Red Hat EL 7.4.

[Ebiroll]

Works fine on Centos 7.3. Good job!

Visual Studio Code still needs libraries: libXss.so.1 that is available in libXScrnSaver

If you get, code: error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory
try,
$ yum install libXScrnSaver

$ ldd Microsoft.VSCode.CPP.Extension.linux
linux-vdso.so.1 => (0x00007ffe155fa000)
libm.so.6 => /lib64/libm.so.6 (0x00007f459e4dd000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f459e2c1000)
libc.so.6 => /lib64/libc.so.6 (0x00007f459deff000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f459dcfb000)
librt.so.1 => /lib64/librt.so.1 (0x00007f459daf3000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f459d8dc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f459e7fa000)
$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)

[sean-mcmanus]

@Ebiroll What do you mean by "Code still needs libraries"? Is this something our extension should fix? I didn't see that error on my CentOS7 and I didn't run the "yum install libXScrnSaver".

[s-martin]

Thanks. I'll check it out!

[Ebiroll]

@sean-mcmanus Sorry, to be more specific there exist a not so obvious dependency from Visual Studio Code to libXss.so.1 that is available in libXScrnSaver.
This should probably not be a problem if you install from the rpm. The extension seems to work fine under redhat/centos.

[s-martin]

CentOS 7.4:

I had first to deinstall the 0.14.3 extension and then after a restart install the 0.14.4.-insider, but now it works seamless.

[s-martin]

I want to say thank you to finally fixing this, even if RHEL/CentOS was not your targeted audience.

[GabeAl]

I tried installing using

code --install-extension cpptools-linux.vsix

It reported installation was successful. Then when I opened Code, it auto-downloaded an older version, installed that one, and promptly displayed "The language server crashed 5 times..."

[sean-mcmanus]

As others have mentioned, the 0.14.3 version needs to be uninstalled or VS Code will continue to use the old one instead.

@GabeAl I'm not observing that behavior on my CentOS machine? What OS are you using? For me, the 0.14.4-insider stays installed...did you have the 0.14.3 version installed previously?

@s-martin Thanks to everyone who complained. We try to use user feedback to help prioritize our work.

[carlhua]

works perfectly now.

On Mon, Dec 4, 2017 at 12:56 PM, Sean McManus [e-mail]
wrote:

Ah, yeah -- as others have mentioned, the 0.14.3 version needs to be
uninstalled or VS Code will continue to use the old one instead.

@GabeAl https://github.com/gabeal I'm not observing that behavior on my
CentOS machine? What OS are you using? For me, the 0.14.4-insider stays
installed...did you have the 0.14.3 version installed previously?

@s-martin https://github.com/s-martin Thanks to everyone who
complained. We try to use user feedback to help prioritize our work.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode-cpptools/issues/19#issuecomment-349102461,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKW214IDM9-RX6jBs3ZT6wei01u3bPmPks5s9FxlgaJpZM4ILN70
.

[carlhua]

thank you so much!!!!

On Mon, Dec 4, 2017 at 2:51 PM, Carl Hua [e-mail] wrote:

works perfectly now.

On Mon, Dec 4, 2017 at 12:56 PM, Sean McManus [e-mail]
wrote:

Ah, yeah -- as others have mentioned, the 0.14.3 version needs to be
uninstalled or VS Code will continue to use the old one instead.

@GabeAl https://github.com/gabeal I'm not observing that behavior on
my CentOS machine? What OS are you using? For me, the 0.14.4-insider stays
installed...did you have the 0.14.3 version installed previously?

@s-martin https://github.com/s-martin Thanks to everyone who
complained. We try to use user feedback to help prioritize our work.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode-cpptools/issues/19#issuecomment-349102461,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKW214IDM9-RX6jBs3ZT6wei01u3bPmPks5s9FxlgaJpZM4ILN70
.

[GabeAl]

Thanks for pointing that out -- no, I had a version earlier than 0.14.3 installed when I tried the 0.14.4 preview. I tried uninstalling and re-installing. I'm on CentOS 7.4.

It seems this is the correct version but still crashes.

Thinking back, I had used one of the earlier workarounds before which could be causing trouble now. I had forgotten about this because even though the workaround worked at the time, the plugin kept auto-updating and I ignored it since then, thinking all of the workaround had been un-done.

Is there a way to completely purge VS-code and re-install anew? I can try yum remove, but I think there might be some lingering config files/directories in the system along with the workaround's hacked execution scripts.

[GabeAl]

Removing and re-installing code with yum, and clearing ~/.vscode did the trick. I saw cpptools roar triumphantly to life. :hamburger:

Now I'm off to excitedly explore how to use it. Currently it chokes when it sees the #include for immintrin.h (the x86 assembly intrinsics), which seems to be keeping other declarations from showing up (no tooltips for malloc, etc until I comment it out). I have a feeling this is a different issue (something about includePaths), but thought I'd post just for completeness!

Thanks again!

[ampatel21]

Thanks for addressing this issue.

[ericsdakcs]

I can confirm, it works great on CentOS 7.4, glibc 2.17. In fact, it's running faster than when I was using the workaround.

Thanks for fixing this! It makes my job easier...

[JohnW71]

The insider version is now working for me on RedHat 7.4, thanks a lot for resolving this!

[sean-mcmanus]

Fixed with 0.14.4.

[bobbrow]

We recommend uninstalling the 0.14.4-insider version of the extension and installing the official 0.14.4 version now. I will remove the link to the insider version from this thread.

[dorinlazar]

Thank you. The fix works awesomely! :)

[dcourtois]

Yay same here !