Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLIBC 2.18 dependency #19

Closed
delmyers opened this issue Apr 19, 2016 · 65 comments
Closed

GLIBC 2.18 dependency #19

delmyers opened this issue Apr 19, 2016 · 65 comments
Labels
bug fixed Check the Milestone for the release in which the fix is or will be available. Language Service
Milestone

Comments

@delmyers
Copy link
Contributor

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

@Ebiroll
Copy link

Ebiroll commented May 16, 2016

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
Copy link
Contributor

pieandcakes commented Jul 23, 2016

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

@bfarley792
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor Author

@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
Copy link

mk3890 commented Sep 20, 2016

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

@ampatel21
Copy link

ampatel21 commented Sep 21, 2016

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

  1. 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
Copy link

Ebiroll commented Sep 22, 2016

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
Copy link

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
Copy link

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
Copy link

Ebiroll commented Dec 10, 2016

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
Copy link

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
Copy link

Ebiroll commented Dec 12, 2016

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
Copy link

fradav commented Mar 15, 2017

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
Copy link
Collaborator

sean-mcmanus commented Dec 1, 2017

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
Copy link

dtrudg commented Dec 1, 2017

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

@Ebiroll
Copy link

Ebiroll commented Dec 1, 2017

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
Copy link
Collaborator

@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
Copy link

s-martin commented Dec 1, 2017

Thanks. I'll check it out!

@Ebiroll
Copy link

Ebiroll commented Dec 2, 2017

@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
Copy link

s-martin commented Dec 4, 2017

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
Copy link

s-martin commented Dec 4, 2017

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

@GabeAl
Copy link

GabeAl commented Dec 4, 2017

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
Copy link
Collaborator

sean-mcmanus commented Dec 4, 2017

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
Copy link

carlhua commented Dec 4, 2017 via email

@carlhua
Copy link

carlhua commented Dec 4, 2017 via email

@GabeAl
Copy link

GabeAl commented Dec 5, 2017

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.

image

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
Copy link

GabeAl commented Dec 5, 2017

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
Copy link

Thanks for addressing this issue.

@ericsdakcs
Copy link

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
Copy link

JohnW71 commented Dec 11, 2017

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

@sean-mcmanus
Copy link
Collaborator

Fixed with 0.14.4.

@bobbrow
Copy link
Member

bobbrow commented Dec 12, 2017

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
Copy link

Thank you. The fix works awesomely! :)

@dcourtois
Copy link

Yay same here !

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug fixed Check the Milestone for the release in which the fix is or will be available. Language Service
Projects
None yet
Development

No branches or pull requests