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

[ericgross2]

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:

0. wget http://ftp.gnu.org/gnu/glibc/glibc-2.18.tar.xz
1. tar xvf glibc-2.18.tar.xz
2. cd glibc-2.18
3. mkdir build
4. cd build
5. ../configure --prefix=/opt/glibc-2.18
6. sudo make install
7. 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  

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

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

[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 ***@***.***> 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 <#19 (comment)>, 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 ***@***.***> wrote: works perfectly now. On Mon, Dec 4, 2017 at 12:56 PM, Sean McManus ***@***.***> 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 > <#19 (comment)>, > 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. 🍔

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 !