When i use clang with libc++, KDevelop still uses the libstdc++ headers causing all kinds of problems with library types that aren't yet included in libstdc++. After an initial investigation i am guessing the include paths are discovered from GccLikeCompiler::includes. Unfortunately using "clang++ -E -v" only shows the default settings that clang was compiled with, which is the libstdc++ setup. Using "clang++ -Wp,-v" however shows the include paths that are actually used. The same options also work for g++ too. The only problem is that it then expects an input file so i would suggest "clang++ -Wp,-v dummy.cpp -fsyntax-only" Reproducible: Always
I think you just need to pass `-stdlib=libc++` to the compiler from the compiler settings dialog. That should - hopefully - work. I'll keep this bug open, as we should make it simpler to switch between the libs, and potentially read that data from CMake directly, if possible.
I am not using CMake. I already am adding -stdlib=libc++ to the parser command line (Right click project -> Open Configuration -> Language support -> C/C++ Parser and setting a custom profile with -stdlib=libc++). I think the problem is simply that clang returns the wrong details with -E -v. Note the warning about not using the the stdlib argument. [john@aglap ~]$ clang++ -E -v clang version 3.7.1 (tags/RELEASE_371/final) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib64/gcc/x86_64-unknown-linux-gnu/5.3.0 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0 Candidate multilib: .;@m64 Selected multilib: .;@m64 [john@aglap ~]$ clang++ -E -v -stdlib=libc++ clang version 3.7.1 (tags/RELEASE_371/final) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib64/gcc/x86_64-unknown-linux-gnu/5.3.0 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0 Candidate multilib: .;@m64 Selected multilib: .;@m64 clang-3.7: warning: argument unused during compilation: '-stdlib=libc++' [john@aglap ~]$ clang++ -Wp,-v dummy.cpp -fsyntax-only clang -cc1 version 3.7.1 based upon LLVM 3.7.1 default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0 /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/x86_64-unknown-linux-gnu /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/backward /usr/local/include /usr/bin/../lib/clang/3.7.1/include /usr/include End of search list. [john@aglap ~]$ clang++ -Wp,-v dummy.cpp -fsyntax-only -stdlib=libc++ clang -cc1 version 3.7.1 based upon LLVM 3.7.1 default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/bin/../include/c++/v1 /usr/local/include /usr/bin/../lib/clang/3.7.1/include /usr/include End of search list.
My apologies. It is still not working, although i may well be completely wrong about the cause of the problem because if the detection is through GccLikeCompiler::includes, then i don't think it would succeed at parsing any of the -E -v output anyway because it doesn't match what the code is looking for.
Your command is wrong/incomplete: clang++ -std=c++11 -xc++ -dM -E -v /dev/null vs clang++ -std=c++11 -stdlib=libc++ -xc++ -dM -E -v /dev/null I get different output as expected.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.