cpptools seems not to be receiving compiler path from CMake Tools

[DavidA2014]

Type: LanguageService

• OS and Version: Windows 10 1803 host with remote ssh access to Centos 7.6
• VS Code Version: 1.35.1
• C/C++ Extension Version: 0.23.1
• Other extensions you installed (and if the issue persists after disabling them): vscode-cmake-tools 1.1.3

I am running a remote session over SSH to a Centos 7.6 machine. Centos 7.6 has gcc 4.8 by default, which doesn't support C++14, so I have installed the RHEL Developer Toolset 7 to give gcc 7.3.1 to support C++14.

I've set env variable:

CXX=/opt/rh/devtoolset-7/root/usr/bin/g++

and CMake (and vscode-cmake-tools extension) adopts that version as the default compiler:

message(STATUS "Compiler path: " ${CMAKE_CXX_COMPILER})

gives:

[cmake] Compiler path: /opt/rh/devtoolset-7/root/usr/bin/g++

but my source code has:

#if __GNUC__ && (__cplusplus < 201402L)
#error Requires a C++14 compliant compiler (gcc 5 or greater)
#endif  

and I get a red squiggle:

The workspaces settings.json contains:

{
    "C_Cpp.default.configurationProvider": "vector-of-bool.cmake-tools",
    "cmake.buildDirectory": "${workspaceRoot}/${buildType}"
}

Should vscode-cmake-tools provide the compiler path to the cpptools or do I need to specify it separately in cpptools settings?

[sean-mcmanus]

There is a compilerPath path property in our vscode-cpptool-api that the CMake Tools extension could set, but it may not be set -- you can check if it's being set or not via enabling debug logging. If they don't set it, then it could a bug with the CMake Tools extension. I believe setting the compilerPath yourself will work because we don't use that if a custom configuration provider is being used.

[DavidA2014]

Thanks for your reply. I have created an issue in the CMake Tools repo: microsoft/vscode-cmake-tools#702.

Actually, I'm not sure that CMake Tools isn't providing the correct compilerPath. The cpptools debug output does not appear to show it. What I do know from the cpptools debug info is that the browse path is set to the g++ 4.8.2 header files (as shown in the output shown in the above CMake Tools issue).

I don't know where g++ 7.3.1 from devtoolset 7 gets its include files. Would it use the 4.8.2 files? If not where are they? This would enable me to manually set the cpptools browse path. Sorry, that this is not an appropriate question for cpptools issues, but if you have any thoughts I would be grateful.

[DavidA2014]

Update: I have identified devtoolset 7's include paths:

$ cpp -v
Using built-in specs.
COLLECT_GCC=cpp
<snip>
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
<snip>
#include "..." search starts here:
#include <...> search starts here:
 /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/include
 /usr/local/include
 /opt/rh/devtoolset-7/root/usr/include
 /usr/include
End of search list.

So I tried adding these to settings.json:

"C_Cpp.default.includePath": ["/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/include",
                              "/opt/rh/devtoolset-7/root/usr/include/"],
"C_Cpp.default.browse.path": ["/opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/include",
                              "/opt/rh/devtoolset-7/root/usr/include/"]

But cpptools is still assuming gcc 4.8.2:

[sean-mcmanus]

It looks like the configuration provider is not being used at all (for compilerPath or anything else like includePath). It seems like we need to investigate how this could happen and/or add more logging in regards to what is failing.

[DavidA2014]

@sean-mcmanus Thanks for looking into this.

[bobbrow]

We added more logging that would help us diagnose the issue. If you are still seeing this problem, could you run the "Log Diagnostics" command and share with us what you see?

[github-actions]

This issue has been closed automatically because it needs more information and has not had recent activity.