rtags can not find include, while clang can: libcxx + include_next

[Dushistov]

I try to index https://github.com/mapsme/omim project. To do that I create two soft symlinks:

$ ls -l ~/bin/rtags/clang
lrwxrwxrwx 1 evgeniy evgeniy 53 сен 22 00:33 /home/evgeniy/bin/rtags/clang -> /home/evgeniy/projects/rtags/bin/gcc-rtags-wrapper.sh
$ ls -l ~/bin/rtags/clang++
lrwxrwxrwx 1 evgeniy evgeniy 53 сен 22 00:33 /home/evgeniy/bin/rtags/clang++ -> /home/evgeniy/projects/rtags/bin/gcc-rtags-wrapper.sh

clang is only officially supported compiler, so I'm not use gcc.

After compiling with ./omim/tools/unix/build_omim.sh -d (it call qmake and then make), I got for the most of files such error:

Output from /home/evgeniy/projects/maps_libraries/mapsme/omim/drape_frontend/backend_renderer.cpp:
CI::parse: List<String>(-c, -pipe, -stdlib=libc++, -fdata-sections, -ffunction-sections, -O3, -ffast-math, -g, -fPIC, -std=gnu++11, -Wall, -W, -Wno-sign-compare, -Wno-strict-aliasing, -Wno-unused-parameter, -Wno-unused-local-typedef, -Wno-sign-conversion, -Werror=return-type, -ferror-limit=50, -Wall, -fspell-checking, -Wno-unknown-warning-option, -DQT_NO_DEBUG, -DRELEASE, -D_REENTRANT, -D_RELEASE, -I/home/evgeniy/projects/maps_libraries/mapsme/omim/drape_frontend, -I/home/evgeniy/projects/maps_libraries/mapsme/omim-build-release/drape_frontend/, -I/home/evgeniy/projects/maps_libraries/mapsme/omim, -I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/boost, -I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/glm, -I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/protobuf/src, -I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/expat/lib, -I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/freetype/include, -I/usr/lib64/qt5/mkspecs/linux-clang-libc++)

/usr/include/c++/v1/cstddef:43:15: fatal error: 'stddef.h' file not found
CI::parse loading unit: clang "-c" "-pipe" "-stdlib=libc++" "-fdata-sections" "-ffunction-sections" "-O3" "-ffast-math" "-g" "-fPIC" "-std=gnu++11" "-Wall" "-W" "-Wno-sign-compare" "-Wno-strict-aliasing" "-Wno-unused-parameter" "-Wno-unused-local-typedef" "-Wno-sign-conversion" "-Werror=return-type" "-ferror-limit=50" "-Wall" "-fspell-checking" "-Wno-unknown-warning-option" "-DQT_NO_DEBUG" "-DRELEASE" "-D_REENTRANT" "-D_RELEASE" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim/drape_frontend" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim-build-release/drape_frontend/" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/boost" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/glm" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/protobuf/src" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/expat/lib" "-I/home/evgeniy/projects/maps_libraries/mapsme/omim/3party/freetype/include" "-I/usr/lib64/qt5/mkspecs/linux-clang-libc++" /home/evgeniy/projects/maps_libraries/mapsme/omim/drape_frontend/backend_renderer.cpp true

The interesting part, that if take take command line from rdm copy + paste and exec from shell all works without errors.

lines where error occurred:

// Don't include our own <stddef.h>; we don't want to declare ::nullptr_t.
#include_next <stddef.h>
#include <__nullptr>

so #include_next for some reason rtags can not handle, while clang can, libclang come with clang in the same package.

I tried to give rdm option --isystem /usr/include/c++/v1 there is stddef.h there:

$ ls /usr/include/c++/v1/stddef.h 
/usr/include/c++/v1/stddef.h

Also I try to give rdm path to gcc stddef.h:

$ ls /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/include/stddef.h 
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/include/stddef.h

via --isystem /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/include, but this also not helps, I still got: /usr/include/c++/v1/cstddef:43:15: fatal error: 'stddef.h' file not found

combination of options also not works rdm --isystem /usr/include/c++/v1 --isystem /usr/lib64/gcc/x86_64-pc-linux-gnu/5.3.0/include

[brucestephens]

For what little it's worth, I've been getting the same problem recently (also with stddef.h). I wondered if it was a change in llvm/clang, but switching to the llvm/clang 3.9 didn't help. (Haven't tried with RTAGS_BUILD_CLANG yet.)

Adding this to ~/.rdmrc seems to fix it, so presumably something has changed and the include order is wrong, somewhere?

--isystem=/usr/local/include/c++/v1
--isystem=/usr/local/lib/clang/4.0.0/include

[Dushistov]

@brucestephens I solved this issue for me in the similar way as you suggested. Took paths from clang++ -E -x c++ - -v < /dev/null and used them in rdm command line:

/bin/rdm -v -v -j4 --isystem /usr/include/c++/v1 --isystem /usr/include/c++/v1 --isystem /usr/bin/../lib/clang/3.8.1/include --isystem /usr/include

I wonder why libclang have no right include order

[Andersbakken]

I've had a similar problems in the past but I can't quite remember how I solved them.

When rdm starts it should print out the actual path for its system include. E.g.

(master)[abakken@lgml-abakken1:~/dev/rtags] rdm Running with 8 jobs, using args: -ferror-limit=50 -Wall -fspell-checking -Wno-unknown-warning-option Includepaths: -isystem /usr/local/Cellar/llvm38/3.8.0/lib/llvm-3.8/lib/clang/3.8.0/include/

Does that path not contain stddef.h?

regards

Anders

On Wed, Oct 5, 2016 at 11:36 PM, Evgeniy Dushistov <notifications@github.com

wrote:

@brucestephens https://github.com/brucestephens I solved issue for me in similar way, but taking paths from clang++ -E -x c++ - -v < /dev/null and use them in rdm command line:

/bin/rdm -v -v -j4 --isystem /usr/include/c++/v1 --isystem /usr/include/c++/v1 --isystem /usr/bin/../lib/clang/3.8.1/include --isystem /usr/include

I wonder why libclang have no right include order

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/811#issuecomment-251879071, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSjXOM-jmEguMeX6Z7Fc28T4d5GwRks5qxJb4gaJpZM4KMCIr .

[brucestephens]

Mine gives an empty Includepaths:

brs% rdm
Running with 4 jobs, using args: -ferror-limit=50 -Wall -fspell-checking -Wno-unknown-warning-option
Includepaths:

[Andersbakken]

Hm. That's interesting. Very likely the directory structure of your libclang install is different from what we expect. How did you install your clang? What system is this on?

Can you apply this patch and see what it outputs when you start rdm?

$ git diff HEAD -- /home/abakken/dev/rtags/src/Server.cpp diff --git a/src/Server.cpp b/src/Server.cpp index 87b29a5..411855a 100644 --- a/src/Server.cpp +++ b/src/Server.cpp @@ -156,6 +156,7 @@ bool Server::init(const Options &options) for (Path systemInclude : sSystemIncludePaths) { systemInclude = systemInclude.ensureTrailingSlash(); systemInclude << "clang/" << CLANG_VERSION_STRING << "/include/";

•      error() << "checking system include dir" << systemInclude <<

  systemInclude.isDir(); if (systemInclude.isDir()) {

  mOptions.includePaths.append(Source::Include(Source::Include::Type_System, systemInclude)); break;

regards

Anders

On Sun, Oct 9, 2016 at 10:57 AM, Bruce Stephens notifications@github.com wrote:

Mine gives an empty Includepaths:

brs% rdm Running with 4 jobs, using args: -ferror-limit=50 -Wall -fspell-checking -Wno-unknown-warning-option Includepaths:

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/811#issuecomment-252501498, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSiZxH7PicAL5y3QfDGNpS8dQHtYrks5qySsBgaJpZM4KMCIr .

[brucestephens]

OK, looks like an llvm build issue. I get

checking system include dir /usr/local/stow/clang/lib/clang/4.0.0svn/include/ false
checking system include dir /usr/lib/clang/4.0.0svn/include/ false
Running with 4 jobs, using args: -ferror-limit=50 -Wall -fspell-checking -Wno-unknown-warning-option

and that seems to be because llvm-config --version is returning 4.0.0svn. The actual include directory has a version of just 4.0.0.

I'm building llvm and clang from their git mirror, so presumably something is slightly messed up with that. Anyway, probably not an rtags issue (though I guess the configure might try removing svn if the version ends with that).

[ambihelical]

Just as a data point (I'm having the same problem), I get the following:

checking system include dir /usr/local/rtags-llvmclang/lib/clang//include/ false
checking system include dir /usr/lib/clang//include/ false
Running with 8 jobs, using args: -ferror-limit=50 -Wall -fspell-checking -Wno-unknown-warning-option
Includepaths:

I have RTAGS_BUILD_CLANG set The path it should be checking in the first line is /usr/local/rtags-llvmclang/lib/clang/3.8.1/include So the 3.8.1 is missing for some reason.

[Dushistov]

Hm. That's interesting. Very likely the directory structure of your libclang install is different from what we expect. How did you install your clang? What system is this on?

Gentoo/Linux, installed via package manager.

Can you apply this patch and see what it outputs when you start rdm?

checking system include dir /usr/local/lib/clang//include/ false checking system include dir /usr/lib/clang//include/ false

none of these directories exists.

clang (libclang come with clang in one package):

$ clang++ -E -x c++ - -v < /dev/null 2>&1 | awk 'BEGIN{v=0}  /#include <...> search starts here/ {v=1} /End of search list/{v=0} {  if (v!=0) print $0;}'
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5
 /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5/backward
 /usr/local/include
 /usr/bin/../lib/clang/3.8.1/include
 /usr/include

[brucestephens]

Odd that llvm-config (or clang itself) doesn't have some easy way to get this directory (though the output above looks like it might be workable with a bit of effort). Maybe it's OK just to let the user add the directory to ~/.rdmrc? Or run clang -MD on a file containing #include <stddef.h> and parse the .d file to find where stddef.h really is.

[Andersbakken]

Hi Bruce

Adding it to ~/.rdmrc definitely works.

There's also some functionality in rdm to do something similar to the latter. You can enable it by adding this to your ~/.rdmrc:

--enable-compiler-manager

or

-R

I feel like we should be able to query something at build time to determine where the includes reside though. Maybe pkg-config or something?

Anders

On Mon, Oct 10, 2016 at 2:52 PM, Bruce Stephens notifications@github.com wrote:

Odd that llvm-config (or clang itself) doesn't have some easy way to get this directory (though the output above looks like it might be workable with a bit of effort). Maybe it's OK just to let the user add the directory to ~/.rdmrc? Or run clang -MD on a file containing #include and parse the .d file to find where stddef.h really is.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/811#issuecomment-252756118, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSjgSa7AGBzAY7Vx3O9ELCNlYeoloks5qyrOUgaJpZM4KMCIr .

[jbeigel]

I just noticed that /usr/lib/rtags-llvmclang does not contain a llvm-config binary. Could that be part of the problem, that llvm-config is not built when using RTAGS_BUILD_CLANG?

Or - if this is already fixed - is there a way to _re_build clang via RTAGS_BUILD_CLANG?

[Andersbakken]

Ah. I get it. I updated the CMakeLists.txt file to make sure RTAGS_BUILD_CLANG also builds llvm-config

Does this work better?

regards

Anders

On Thu, Oct 13, 2016 at 4:40 AM, Johannes Beigel notifications@github.com wrote:

I just noticed that /usr/lib/rtags-llvmclang does not contain a llvm-config binary. Could that be part of the problem, that llvm-config is not built when using RTAGS_BUILD_CLANG?

Or - if this is already fixed - is there a way to _re_build clang via RTAGS_BUILD_CLANG?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/811#issuecomment-253489544, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSibQtU2t7HXduudxizDzbW-5HL9pks5qzhidgaJpZM4KMCIr .

[jbeigel]

llvm-config is now built and installed into /usr/local/rtags-llvmclang/bin, but I still get an empty includepaths output from rdm.

[ambihelical]

Ditto. Also the paths that it checks (output via your patch above) seem to be missing the version component of the path. How is this picked up?

[Andersbakken]

I think I've found the issue. We're actually not using llvm-config when building clang as part of rtags. We should be doing it now however and from a simple test it seems to work for me. Can you guys check?

[ambihelical]

I tried building with the following in a build directory: The output without --no-install is similar, except it involves an intermediate sudo make llvmclang when the build craps out because I'm not root normally.

../configure --build-clang --no-install
[output of configure shown later]
make -j8
[lots of compile output removed]
In file included from /home/xxxx/extern/rtags/src/ClangThread.cpp:16:0:
/home/xxxx/extern/rtags/src/ClangThread.h:19:27: fatal error: clang-c/Index.h: No such file or directory
 #include <clang-c/Index.h>
                           ^
compilation terminated.
[more output like that]

Here is the output of configure script:

eb…th@jh…eb:rtags@master:~/extern/rtags/build$ ../configure --build-clang --no-install
Running cmake:
"cmake" ".." -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DRTAGS_NO_INSTALL=1 -DRTAGS_BUILD_CLANG=1

-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/ccache/c++
-- Check for working CXX compiler: /usr/lib/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- llvm-config executable found: /usr/bin/llvm-config
-- Using Clang version 3.4 from /usr/lib/llvm-3.4/lib with CXXFLAGS -I/usr/lib/llvm-3.4/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-- Found LibClang: -L/usr/lib/llvm-3.4/lib;-lclang;-Wl,-rpath,/usr/lib/llvm-3.4/lib  
-- Looking for backtrace
-- Looking for backtrace - found
-- Looking for CLOCK_MONOTONIC_RAW
-- Looking for CLOCK_MONOTONIC_RAW - found
-- Looking for CLOCK_MONOTONIC
-- Looking for CLOCK_MONOTONIC - found
-- Looking for mach_absolute_time
-- Looking for mach_absolute_time - not found
-- Looking for inotify_init
-- Looking for inotify_init - found
-- Looking for kqueue
-- Looking for kqueue - not found
-- Looking for epoll_wait
-- Looking for epoll_wait - found
-- Looking for select
-- Looking for select - found
-- Looking for FD_CLOEXEC
-- Looking for FD_CLOEXEC - found
-- Looking for SO_NOSIGPIPE
-- Looking for SO_NOSIGPIPE - not found
-- Looking for MSG_NOSIGNAL
-- Looking for MSG_NOSIGNAL - found
-- Looking for GetLogicalProcessorInformation
-- Looking for GetLogicalProcessorInformation - not found
-- Looking for SCHED_IDLE
-- Looking for SCHED_IDLE - found
-- Looking for SHM_DEST
-- Looking for SHM_DEST - found
-- Performing Test HAVE_STATMTIM
-- Performing Test HAVE_STATMTIM - Success
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8") 
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing:  OPENSSL_LIBRARIES OPENSSL_INCLUDE_DIR) 
OPENSSL Can't be found. Rct configured without openssl support
-- Performing Test HAVE_CXX11
-- Performing Test HAVE_CXX11 - Success
-- Performing Test HAVE_UNORDERDED_MAP_WORKING_MOVE_CONSTRUCTOR
-- Performing Test HAVE_UNORDERDED_MAP_WORKING_MOVE_CONSTRUCTOR - Success
-- 
-- The following OPTIONAL packages have been found:

 * ZLIB
 * PkgConfig , helper tool , <https://www.freedesktop.org/wiki/Software/pkg-config/>
   We use it to get the bash completion installation path, and replace the prefix with the value of CMAKE_INSTALL_PREFIX.

-- The following REQUIRED packages have been found:

 * LibClang

-- The following OPTIONAL packages have not been found:

 * OpenSSL

-- Configuring done
-- Generating done
-- Build files have been written to: /home/xxxx/extern/rtags/build

[ambihelical]

I noticed I have a later clang/llvm available in my distribution's repo. After installing clang-3.8 (which pulls in llvm-3.8), the build succeeds. And rtags appears to be working.

It's using the system llvm-3.8 directory though, the clang I built seems to be ignored:

checking system include dir /usr/lib/llvm-3.8/lib/clang/3.8.0/include/ true
Running with 8 jobs, using args: -ferror-limit=50 -Wall -fspell-checking -Wno-unknown-warning-option
Includepaths: -isystem /usr/lib/llvm-3.8/lib/clang/3.8.0/include/

[azuk]

brucestephens wrote:

and that seems to be because llvm-config --version is returning 4.0.0svn. The actual include directory has a version of just 4.0.0.

I'm building llvm and clang from their git mirror, so presumably something is slightly messed up with that. Anyway, probably not an rtags issue (though I guess the configure might try removing svn if the version ends with that).

I faced the same problem when I built the latest clang and tried to use rtags with it. clang itself finds its include files fine (I can build, for example, rtags with clang but rtags cannot index itself) and I'm a bit sceptical if it is a good idea to make assumptions about the directory layout the way rtags does.

I'm not familiar how rtags uses clang but I wonder if it was possible for rtags to use clang's HeaderSearch / HeaderSearchOptions classes? The issue of determining system include paths has come up years ago on clang mailing list http://clang-developers.42468.n3.nabble.com/How-to-determine-clang-s-system-include-dirs-to-set-in-ASTVisitor-td4029080.html and it sounds like relevant default options haven't worked in an expected way but perhaps things have changed.

[Andersbakken]

It probably would help us with this but we're using the public C-api, not libtooling. We have considered switching to using the c++ api since it gives us access to more things but we it would be quite a bit of work. Also, they do break source-compatibility in those APIs with some frequency.

Anders

On Mon, Nov 7, 2016 at 5:56 AM, Hannu Koivisto notifications@github.com wrote:

brucestephens wrote:

and that seems to be because llvm-config --version is returning 4.0.0svn. The actual include directory has a version of just 4.0.0.

I'm building llvm and clang from their git mirror, so presumably something is slightly messed up with that. Anyway, probably not an rtags issue (though I guess the configure might try removing svn if the version ends with that).

I faced the same problem when I built the latest clang and tried to use rtags with it. clang itself finds its include files fine (I can build, for example, rtags with clang but rtags cannot index itself) and I'm a bit sceptical if it is a good idea to make assumptions about the directory layout the way rtags does.

I'm not familiar how rtags uses clang but I wonder if it was possible for rtags to use clang's HeaderSearch / HeaderSearchOptions classes? The issue of determining system include paths has come up years ago on clang mailing list http://clang-developers.42468.n3.nabble.com/How-to- determine-clang-s-system-include-dirs-to-set-in-ASTVisitor-td4029080.html and it sounds like relevant default options haven't worked in an expected way but perhaps things have changed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/811#issuecomment-258841499, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSiSRTgNO-wtGm8VY8fbGool5IGwCks5q7y4bgaJpZM4KMCIr .

[ambihelical]

I don't know if this is the correct fix, but after I changed src/CMakeLists.txt according the following diff, and installed rtags, I got the correct startup IncludesPaths printed in rdm's log, at least for the case when building clang during install (configure --build-clang):

diff --git i/src/CMakeLists.txt w/src/CMakeLists.txt
index ae09286..3d7ab32 100644
--- i/src/CMakeLists.txt
+++ w/src/CMakeLists.txt
@@ -24,6 +24,7 @@ if (RTAGS_BUILD_CLANG)
     if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
         add_definitions("-DCLANG_INCLUDE=${CLANG_INSTALL_PATH}/include/c++/v1") # add libcxx include
     endif ()
+        set(LIBCLANG_LLVM_CONFIG_EXECUTABLE ${CLANG_INSTALL_PATH}/bin/llvm-config)
 endif ()

[Andersbakken]

I think that is a good fix. I applied it. Thanks.

Anders

On Fri, Nov 11, 2016 at 5:23 PM, ambihelical notifications@github.com wrote:

I don't know if this is the correct fix, but after I changed src/CMakeLists.txt according the following diff, and installed rtags, I got the correct startup IncludesPaths printed in rdm's log, at least for the case when building clang during install (configure --build-clang):

diff --git i/src/CMakeLists.txt w/src/CMakeLists.txt index ae09286..3d7ab32 100644 --- i/src/CMakeLists.txt +++ w/src/CMakeLists.txt @@ -24,6 +24,7 @@ if (RTAGS_BUILD_CLANG) if (CMAKE_SYSTEM_NAME MATCHES "Darwin") add_definitions("-DCLANG_INCLUDE=${CLANG_INSTALL_PATH}/include/c++/v1") # add libcxx include endif ()

• set(LIBCLANG_LLVM_CONFIG_EXECUTABLE ${CLANG_INSTALL_PATH}/bin/llvm-config) endif ()

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Andersbakken/rtags/issues/811#issuecomment-260091699, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEdSuUwugZrV4-IIMaTYRWatEqtKqyXks5q9RT9gaJpZM4KMCIr .

[baolonglin]

Yesterday I compiled the latest rtags with -DRTAGS_BUILD_CLANG=1, the clang version is 5.0.0. Started the rdm with -R, met similar error:

handleInclude failed (nil) inclusion directive include stdlib.h /opt/gcc/6.2.0/include/c++/6.2.0/cstdlib:75:1

It can be solved with @brucestephens solution, append:

--isystem /opt/gcc/6.2.0/include/c++/6.2.0/tr1

But I have several projects compiled with different GCCs.

Looks like the #include_next mess the index procedure.

I found that the source include path append the system include path before the std c++ path, that's why include_next could not find the header file under /usr/include

I patched the code, move the std c++ path above the system include path, it woks fine in my environment, in my environment, the buildinPaths is empty, maybe those paths also need to be moved above the includePaths.

diff --git a/src/CompilerManager.cpp b/src/CompilerManager.cpp
index 7ecf791..fc505d6 100644
--- a/src/CompilerManager.cpp
+++ b/src/CompilerManager.cpp
@@ -180,9 +180,9 @@ void applyToSource(Source &source, Flags<CompilerManager::Flag> flags)
         source.defines << compiler.defines;
     if (flags & IncludeIncludePaths) {
         if (!source.arguments.contains("-nostdinc")) {
-            source.includePaths << compiler.includePaths;
             if (!source.arguments.contains("-nostdinc++"))
                 source.includePaths << compiler.stdincxxPaths;
+            source.includePaths << compiler.includePaths;
             if (!source.arguments.contains("-nobuiltininc"))
                 source.includePaths << compiler.builtinPaths;
         } else if (!strncmp("clang", cpath.fileName(), 5)) {

[Nephyrin]

This issue occurs for me when using an svn build of llvm/clang. The issue appears to be that llvm-config --version outputs 8.0.0svn while still installing files to /usr/lib/clang/8.0.0/include/

I was able to fix this by providing a stub llvm-config that strips svn from --version output -- I think that just needs to be done at the cmake configuration level. Unfortunately I don't know near enough magic-cmake-language to attempt it :(

It would also be nice if rdm failed more gracefully when it cannot find the isystem path -- this actually manifests as a ton of unrelated diagnostics due to missing headers, it took a bit to figure out what was happening.

[cburn11]

This issue occurs for me when using an svn build of llvm/clang. The issue appears to be that llvm-config --version outputs 8.0.0svn

If you are building your own llvm tools, you can set the PACKAGE_VERSION string in the main llvm project to drop the svn suffix:

clifford@clang-container:~/build$ grep "PACKAGE_VERSION" llvm-2019-04-21/CMakeCache.txt
PACKAGE_VERSION:STRING=9.0.0

clifford@clang-container:~/installs$ 2019-04-21/llvm-gcc/bin/llvm-config --version
9.0.0

The default for a clone from https://llvm.org/git/llvm.git or the github mirror has the package version set to to `9.0.0svn':

clifford@clang-container:~/build$ grep "PACKAGE_VERSION" llvm-2019-04-19/CMakeCache.txt
PACKAGE_VERSION:STRING=9.0.0svn

clifford@clang-container:~/installs$ 2019-04-19/llvm-gcc/bin/llvm-config --version
9.0.0svn

[Barricade]

I patched the code, move the std c++ path above the system include path, it woks fine in my environment, in my environment, the buildinPaths is empty, maybe those paths also need to be moved above the includePaths.

diff --git a/src/CompilerManager.cpp b/src/CompilerManager.cpp
index 7ecf791..fc505d6 100644
--- a/src/CompilerManager.cpp
+++ b/src/CompilerManager.cpp
@@ -180,9 +180,9 @@ void applyToSource(Source &source, Flags<CompilerManager::Flag> flags)
         source.defines << compiler.defines;
     if (flags & IncludeIncludePaths) {
         if (!source.arguments.contains("-nostdinc")) {
-            source.includePaths << compiler.includePaths;
             if (!source.arguments.contains("-nostdinc++"))
                 source.includePaths << compiler.stdincxxPaths;
+            source.includePaths << compiler.includePaths;
             if (!source.arguments.contains("-nobuiltininc"))
                 source.includePaths << compiler.builtinPaths;
         } else if (!strncmp("clang", cpath.fileName(), 5)) {

On Mac OS X it seems that source.includePaths << compiler.includePaths; should be at the bottom (after builtinPaths).