Using default .ycm_extra_conf.py, the standard c++11 headers are not found.

[cebrusfs]

I set g:ycm_global_ycm_extra_conf in my vimrc.

let g:ycm_global_ycm_extra_conf = '~/.vim/bundle/YouCompleteMe/cpp/ycm/.ycm_extra_conf.py'

After including a c++11 header unordered_map, I got 'unordered_map' file not found reported by Syntastic plugin.

After adding

'-I',                                                                              
'/usr/include/c++/4.2.1/tr1/'

in flags in .ycm_extra_conf, now my problem is solved.

In default .ycm_extra_conf, the environment didn't include any c++11 headers, but the argument -std=c++11 still in flags?

I think it's strange. Something should be wrong.

I use the mac os 10.7.5 (Lion) and the following is report by :YcmDebugInfo command, hope it helps.

-- Flags for /Users/cebrusfs/test.cpp loaded from /Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/.ycm_extra_conf.py:
-- ['-Wall', '-Wextra', '-Werror', '-Wc++98-compat', '-Wno-long-long', '-Wno-variadic-macros', '-fex
ceptions', '-DNDEBUG', '-DUSE_CLANG_COMPLETER', '-std=c++11', '-x', 'c++', '-isystem', '/Users/cebru
sfs/.vim/bundle/YouCompleteMe/cpp/ycm/../BoostParts', '-isystem', '/System/Library/Frameworks/Python
.framework/Headers', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/../llvm/include'
, '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/../llvm/tools/clang/include', '-I',
 '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/.', '-I', '/Users/cebrusfs/.vim/bundle/YouComple
teMe/cpp/ycm/./ClangCompleter', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tes
ts/gmock/gtest', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tests/gmock/gtest/
include', '-isystem', '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tests/gmock', '-isystem',
 '/Users/cebrusfs/.vim/bundle/YouCompleteMe/cpp/ycm/./tests/gmock/include', '-I', '/Users/cebrusfs/.
vim/bundle/YouCompleteMe/autoload/../python/clang_includes']
-- Has Clang support compiled in: True
-- clang version 3.2 (tags/RELEASE_32/final)

[pedrovanzella]

This didn't work for me.
It keeps saying that random doesn't exist.

Also, I get the same thing as #192.

[oblitum]

I've gone through this too and assumed that the current behavior won't try check clang default include directories from compiler flags as -std=libc++ and -std=c++11 for example. They can be verified with echo | clang -std=c++11 -stdlib=libc++ -v -E -x c++ -

[pedrovanzella]

I found out that YCM keeps adding '-I', '/Users/pedrovanzella /dotfiles/vim/bundle/YouCompleteMe/autoload/../python/clang_includes' to the flags, and this makes compilation fail.

This works fine:

clang++ hello.cpp -Wall -Wextra -Werror -Wno-long-long -Wno-variadic-macros -fexceptions -DNDEBUG -DUSE_CLANG_COMPLETER -std=c++11 -stdlib=libc++ -x c++ -c

This fails:

clang++ hello.cpp -Wall -Wextra -Werror -Wno-long-long -Wno-variadic-macros -fexceptions -DNDEBUG -DUSE_CLANG_COMPLETER -std=c++11 -stdlib=libc++ -x c++ -c -I /Users/pedrovanzella/dotfiles/vim/bundle/YouCompleteMe/autoload/../python/clang_includes

I stripped .ycm_extra_conf.py bare, but YCM keeps adding this to the flags.

[pedrovanzella]

I found this: https://gist.github.com/locojay/4950253

And it works wonders.

Basically, the only include flag you really need is '-isystem', '/usr/lib/c++/v1',.

This should also fix #305.

[Valloric]

The .ycm_extra_conf.py file linked to from the README is an example file, it's not supposed to cover everything for everyone. The flags that are there by default work for YCM; you're supposed to make an extra conf file yourself that best fits your project (usually by modifying the example file). The easiest way is often to just take the same flags you're passing to gcc/clang when you compile your source files.

YCM adds the path to clang_includes because without those clang-specific includes, semantic code completion would be slow. Clang needs to be able to see the files in that folder to operate correctly, no matter what source code you're compiling.

[oblitum]

@Valloric Does that answer whether it's assumed as issue or not for YCM not to be able to automatically include default included header files (which for flags -std=c++11 and -stdlib=libc++ for example, can be easily verified with echo | clang -std=c++11 -stdlib=libc++ -v -E -x c++ -)?.

Just passing the same flags you're passing to gcc/clang when you compile your source files won't lead to working completion, one must know which headers the compiler include by default for a given set of flags, and include those by hand (IIRC, I had to list even simple /usr/local/include).

[Valloric]

@oblitum Yes, that is troubling... I still can't understand why freaking libclang won't use its default header search paths for code completion like it would for normal compilation. I guess we need a way to pull out the default search paths and append them. Any ideas? We can't call the clang binary because it may not exist on the system. The solution would have to be based on pure libclang.

I know some Clang developers; I'll ask what they think about this.

[oblitum]

@Valloric Sadly, from libclang solely, I've no idea... But, should this issue just be kept closed? At last, this seems a good place for solutions to be brought and, this is indeed a thing newcomers may stumble upon recurrently.

[oblitum]

If not reopened, I think it's a good item for FAQ (I've not checked whether there's one such item already).

[Valloric]

Reopening until we figure this out fully.

[pedrovanzella]

Could we include a few example ycm_extra_conf.py in the README? This sounds like a sensible solution.

[xunfan]

I just have the similar problems and now I have solved them. If standard headers are not found, the good tool to debug is to use :YcmDiages in vim to see the bug information. You will see what errors are there, such as in xxx.h, yyy.h cannot find. Then you will find yyy.h and add the correct include path to the .ycm_extra_conf.py.

Another thing is sometimes the auto-completion cannot find members of a class I defined. The problem is there are errors in :YcmDiages. It seems sometimes if there are errors, ycm stop auto-competion for you...

[sven-strothoff]

On OS X 10.9 with Xcode 5.0.1 you can add

-isystem/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1

to your compile flags to get completion for the STL until there is a proper fix for this issue.
This works if libClang from the Xcode Command Line Tools, i.e. /Library/Developer/CommandLineTools/usr/lib/libclang.dylib is used as external libClang (-DEXTERNAL_LIBCLANG_PATH) when building YCM.

The STL include path can be obtained with (as suggested by @oblitum):
echo | clang -std=c++11 -stdlib=libc++ -v -E -x c++ -

[Valloric]

I've mentioned this issue in the FAQ along with a workaround. I'm looking into a more long-term fix as well, sit tight.

[ofan]

I'm writing this just in case someone else runs into the same problem I hit:
I got YCM (partially) working but when I run :YcmDiags , it gave me a list of errors, but syntax and semantic checking seem partially working

error: no member named int8_t in the global namespace

It's in the cstdint header, apparently clang cannot find the proper stdint.h header, even if I add '/usr/include' in the search directories. The problem is the order of '-I /usr/include' and '-I /opt/local/libexec/llvm-3.3/lib/c++/v1', I simply move the '-I /usr/include' parameter to the front, then the problem is solved, and YCM is now working like a charm.

[bfrg]

I'm having the same issues on my linux machine, too. Unfortunately, the suggested workarounds don't work for me. It's not only the std headers that are not found but also other stuff like eigen3. But for some reasons boost headers are found by default without specifying any additional include directories.

[baronleonardo]

Comment out '-Wc++98-compat' from your ycm_extra_conf.py

[davits]

I have fixed my standard header version incompatibility problems by turning off clang's default standard header paths and adding correct ones.
Hope this will be helpful.

'-nostdinc++',
'-isystem', '/path_to_gcc/include/c++/4.7.2',
'-isystem', '/path_to_gcc/include/c++/4.7.2/x86_64-redhat-linux',
'-isystem', '/path_to_gcc/include/c++/4.7.2/backward',

[dragonxlwang]

Thanks!

[macskay]

For me the only way to get and std::cout / std::endl working was to add

'-I', '/usr/include/c++/5/'
or
'-I', '/usr/include/c++/5.3.1/'

and the -std=c++11 flag inside my .ycm_extra_conf.py

Using Ubuntu MATE 16.04, g++ 5.3.1 (Ubuntu 5.3.1-14ubuntu2) 20160413

Hope this helps

[dragonxlwang]

IMHO there might be a potential problem using -I flag instead of -isystem

[jagerman]

On Linux (at least Ubuntu, probably others as well), the libclang from llvm.org is now working fine. It will find paths to the standard library without issues.

@Valloric Can you confirm that this is still the case with libclang 3.8? I've noticed the problem showing up recently in Debian testing, and after investigating a little, it seems to coincide with an upgraded version of Debian's ycmd, which started being built against clang 3.8 around the middle of April—and, IIRC, that's around the time standard headers stopped being included properly.

I installed Ubuntu 16.04 (which also has ycmd built against clang 3.8) into a virtual machine to test it--same issue: standard headers are not found by default.

I can apply the workaround to get it to work, but that's a nuisance, particularly since the workaround needs to be updated in every project every time stdlibc++ gets a major version upgrade, which is going to be happening more frequently with GCC's new versioning scheme.

We want to make the 99% use-case easy and pain-free; sometimes that means that the 1% use-case is more difficult and it's a price we're willing to pay.

The current situation on Debian/Ubuntu seems to be failing this goal: even a simple C++ hello world doesn't work properly. If this is something Debian and Ubuntu have screwed up in libclang-3.8, responsibility for fixing it obviously goes there, but if this is an upstream llvm change, this really needs a fix either in ycm or upstream llvm.

[agauniyal]

Not working anymore with libclang 3.8. I've tried various conf, '-isystem' as well as '-I' and putting flags from echo | clang -v -E -x c++ -

[puremourning]

If you have a new problem, please raise a new issue, following the instructions in CONTRIBUTING.md

[Hexcles]

Hi @puremourning , I filed #2330 for the new problem (the root problem is still exactly the same though) as reported by @jagerman (and I can also confirm it), in particular discussing the need for Linux workaround similar to the macOS one. Cheers.

[storluffarn]

To anyone who came here searching for answers to how to include eigen (there was this post by @bfrg from 2013), the correct addition to the ycm_extra_conf.py file is: '-isystem', '/usr/include/eigen3', as of today (early 2017).

[riveridea]

With
'-isystem',
'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1'

I still cannot let ycm to find c++ STL names, though all the C++ STL files are in the above directory. Don't know why. I am using MAC running osx 11.

[riveridea]

This is the result after I run
echo | clang -v -E -x c++ -

#include "..." search starts here:

#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks (framework directory)

[vheon]

@riveridea you should try to add

'-isystem',
'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1',
'-isystem',
'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.0.0/include',
'-isystem',
'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include',
'-isystem',
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include'

so all except the one with (framework directory) at the end.

[riveridea]

@vheon It still does not work after I add all the possible paths as you suggested.

[shun-zheng]

I fix this problem by adding the following lines
'-isystem', '/usr/include/c++/4.8', '-isystem', '/usr/include/x86_64-linux-gnu/c++/4.8',
Only providing the path to "iostream" file is not enough, there is an 'include "bits/c++config.h"' statement in "iostream" file, while "bits/c++config.h" is located at '/usr/include/x86_64-linux-gnu/c++/4.8/'.

Running :YcmDiags and you will know what's going wrong

[proudlily]

@macskay hello,where did i to use "'-I', '/usr/include/c++/5/'"? i meet the same problam .

[proudlily]

@macskay hi,i got it .in the ycm_extra_conf.py