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.

3 Likes

That solved the problem, thank you very much!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.