search

microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.53k stars 1.56k forks source link

C++ symbol search and other features not working on Linux install #292

Closed roblourens closed 8 years ago

roblourens commented 8 years ago

From @ericgrossNI on October 17, 2016 18:33

I have used Visual Studio code for quite a few versions on both Windows and Linux. For some reason, none of the symbol database features seem to work on my Linux install. Right-clicking on any symbol or include file only shows "Change all Occurrences", and not peek/go to definition. This works great on Windows. I haven't seen anything in the documentation that says this feature is Windows-only. Am I missing something?

Steps to Reproduce:

  1. Go to any C++ source file.
  2. Right click on C++ symbol.
  3. Note missing options in right-click menu related to symbol

Copied from original issue: Microsoft/vscode#13900

sean-mcmanus commented 8 years ago

I'm not reproing this bug. If the "Go to Definition" is missing then our Microsoft.VSCode.CPP.Extension.linux language server process is completely failing. It's possible your particular Linux distribution doesn't have the required dependencies. We test on Ubuntu 14/16 and Mint. We are known to not support older distributions such as Ubuntu 12 or CentOS7.

ericgross2 commented 8 years ago

Hi,

I am using Scientific Linux 7.2 which has a release date of Feb 5th, 2016, so it isn't terribly old. The various packages included are also up-to-date since then as well.

Can you provide me any details on what dependencies it has that I can check for and provide versions for? Is there any debug output I can check?

I opened the Console output of the developer console and see this listed. I don't know if it is unrelated:

[Extension Host] TypeError: Cannot read property 'forEach' of null at LanguageClient.cleanUp (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/lib/main.js:471:24) at LanguageClient.stop (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/lib/main.js:454:14) at LanguageClient.handleConnectionError (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/lib/main.js:684:18) at errorHandler (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/lib/main.js:559:19) at /home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/lib/main.js:45:42 at CallbackList.invoke (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/node_modules/vscode-jsonrpc/lib/events.js:103:39) at Emitter.fire (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/node_modules/vscode-jsonrpc/lib/events.js:167:36) at writeErrorHandler (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/node_modules/vscode-jsonrpc/lib/main.js:113:22) at CallbackList.invoke (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/node_modules/vscode-jsonrpc/lib/events.js:103:39) at Emitter.fire (/home/labview/.vscode/extensions/ms-vscode.cpptools-0.9.2/node_modules/vscode-languageclient/node_modules/vscode-jsonrpc/lib/events.js:167:36)

Thanks, Eric

sean-mcmanus commented 8 years ago

Can you try going to ~/.vscode/extensions/ms-vscode.cpptools-0.9.2/bin and doing ldd Microsoft.VSCode.CPP.Extension.linux ? And I assume you're using a 64-bit OS. See https://github.com/Microsoft/vscode-cpptools/issues/19 for a potential workaround (getting glibc 2.18).

ericgross2 commented 8 years ago

Thanks, that appears to be it:

$ ldd Microsoft.VSCode.CPP.Extension.linux ./Microsoft.VSCode.CPP.Extension.linux: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./Microsoft.VSCode.CPP.Extension.linux) linux-vdso.so.1 => (0x00007ffc5f5f6000) libm.so.6 => /lib64/libm.so.6 (0x00007fede86b7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fede849b000) libc.so.6 => /lib64/libc.so.6 (0x00007fede80d8000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fede7ed4000) librt.so.1 => /lib64/librt.so.1 (0x00007fede7ccc000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fede7ab5000) /lib64/ld-linux-x86-64.so.2 (0x00007fede89d1000)

$ ls -l /lib64/libc.so.6 lrwxrwxrwx 1 root root 12 Aug 24 03:55 /lib64/libc.so.6 -> libc-2.17.so

Seems like 2.17 is the latest version in the scientific linux repositories. I'm not a guru of glibc versions, but this seems really old, right?

sean-mcmanus commented 8 years ago

Yeah, glibc 2.18 was released in 2013, so 2.17 is 2012 I think. It would be great to get telemetry on how many users are hitting this and also to give a better error message.

ericgross2 commented 8 years ago

I am primarily a Windows user, though I do a lot on Linux VMs these days. I chose Scientific Linux because it is one of the main platforms supported by National Instruments for the test and measurements community (see http://www.ni.com/product-documentation/52786/en/).

I don't understand the rationale behind why some distros still ship ancient versions of glibc (even though they ship new kernels and other features), but it sure seems like there's plenty out there. It would be great if you provided better feedback when this issue occurs, and ideally could build against an older glibc if possible.

ericgross2 commented 8 years ago

Note: I validated the workaround in #19 fixes this issue. Thanks!

sean-mcmanus commented 6 years ago

@ericgrossNI Fixed with 0.14.4.