Rootcling: Incomplete include path?

I am trying to get rootcling to work. I use Arch Linux, installed ROOT from the AUR.
ROOT: 6.10.04
gcc: 7.2.0

When I try to run rootcling, the following happens:

$ rootcling -f output […]
In file included from input_line_1:1:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/new:40:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/exception:142:
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/exception_ptr.h:38:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/cxxabi_init_exception.h:38:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
         ^
In file included from input_line_2:1:
/usr/include/root/RtypesCore.h:25:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
         ^

 *** Break *** segmentation violation

This problem can be circumvented when explicitly supplying the relevant include path or setting CPATH or running as superuser:

$ rootcling -f out -I/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include […]    # works
$ CPATH=${CPATH}:/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include && rootcling -f out […] # works
# rootcling -f out […]    # works

But of course, this is not what should be expected, rootcling should work without all this, running as a normal user. I figure there is some kind of problem with my (build?) environment, but generally compiling works very well, and the relevant path is included:

$ cpp -v
[…]
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include-fixed
 /usr/include
End of search list.

Same for echo | gcc -fsyntax-only -E -v -. So, why doesn’t this work when using rootcling? Root doesn’t know about the path either:

root [0] .include
-I
/etc
-I
/etc/cling
-I
/usr/include/root
-I
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0
-I
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/x86_64-pc-linux-gnu
-I
/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward
-isystem
/usr/local/include
-isystem
/etc/cling/lib/clang/3.9.0/include
-extern-c-isystem
/include
-extern-c-isystem
/usr/include
-resource-dir
/etc/cling/lib/clang/3.9.0
-nostdinc++
root [1] gSystem->GetIncludePath()
(const char *) "-I/usr/include/root -I"/etc" -I"/etc/cling" -I"/usr/include/root" -I"/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0" -I"/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/x86_64-pc-linux-gnu" -I"/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward""

These results don’t look any different when running root as a superuser. However, running #include <stddef.h> in root also only works as a superuser, not for regular users.

stddef.h is a special compiler builtin header (that’s also why GCC is not placing it not in /usr/include/ but in /usr/lib/). As ROOT is using clang behind the scenes, you need to use the stddef.h header of the clang version ROOT is using. It’s placed in /etc/cling/lib/clang/3.9.0/include/stddef.h which is in your include paths.

As it works when you run as root, can you check that it is not a permission issue and that the files are readable by your user?

Note: If you use the GCC header here, you’ll maybe get some funny failures as clang does not expect that its own internal headers are replaced by GCC ones.

That solved the problem, thank you very much!