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

[roblourens]

From @ericgrossNI on October 17, 2016 18:33

• VSCode Version: Code 1.6.1 (9e4e44c19e393803e2b05fe2323cf4ed7e36880e, 2016-10-13T15:43:46.054Z)
• OS Version: Linux x64 3.10.0-327.36.1.el7.x86_64 (Scientific Linux 7)
• Extensions: ms-vscode.cpptools-0.9.2

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]

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]

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]

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 #19 for a potential workaround (getting glibc 2.18).

[ericgross2]

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]

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]

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]

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

[sean-mcmanus]

@ericgrossNI Fixed with 0.14.4.