I’ve been trying to build ROOT from source on my mac laptop today, with c++17 activated. After checking out the code (to a directory called ROOT) and creating a build directory at the same level, I did a cmake-configure with:
But when I attempt to compile I repeatedly get stuck at the following:
In file included from <module-includes>:2:
./include/ROOT/RStringView.hxx:25:10: fatal error: could not build module 'std'
#include <string_view>
~~~~~~~~^
Error: Error loading the default rootcling header files.
make[2]: *** [core/G__Core.cxx] Error 1
I know this is related to me enabling c++17 because if I don’t include that cmake option then the compilation succeeds fine. But I thought c++17 was supported … does anyone know what I’m doing wrong here?
Hi @will_cern ,
needless to say this should not happen Does this also happen if you start the cmake configuration and the build from a completely empty build directory and with no other ROOT installation available in your environment?
Just tried again with an empty directory and also after having done a brew uninstall of my installation of root (which I would have been surprised if was getting in the way, I certainly hadn’t done a source of thisroot.sh in the terminal), but same errors
After much googling I’ve finally found a solution. Seems like there’s some weird issue with system headers clashing with things, which can be, confusingly, solved by editing /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath to replace #include <math.h> with #include "math.h" … I’m too tired to figure out why this works for me but I’m just happy to move on at this point!
Thanks for confirming I wasn’t doing anything stupid with my cmake configure though!
Your bet was right, here’s the first error in fact:
[ 72%] Generating G__Core.cxx, ../lib/Core.pcm
While building module 'Core':
While building module 'std' imported from input_line_1:1:
In file included from <module-includes>:31:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/complex.h:28:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/ccomplex:20:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/complex:245:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:317:9: error: missing '#include "/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/math.h"'; declaration of 'signbit' must be imported
from module 'std.depr.math_h' before it is required
using ::signbit;
I’m coming back to this one because I suspect that my “hack” of cmath in this directory has caused me subsequent grief because I think it ends up using math.h from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/math.h instead of the math.h in the same directory as cmath.
So the real mystery here is why does #include <math.h> fail to find the header in the same location?
to add some further debugging – the original failure, in the dictionary generation of Core, seems to depend on whether -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include appears in the rootcling_stage1 command call or not. If its included, things fail. If I copy the command (from a VERBOSE=1 call to build) then the dictionary generation succeeds if I remove that include.
At this point I’m worried that this version of macOS just isn’t going to work??
So I’ll get the full command for you ASAP but wanted to remark on a difference I spotted between the build CI linked above and my local setup. I noticed that on the CI in the CMakeCache.txt (Sign in to CERN) there is:
Today I tried a fresh build but where I set this cache variable to MacOSX11.1.sdk instead (note that on my machine I seem to have both directories), and the build succeeded. But there are other things I am building in my project (numpy is one of them) and that then failed if I changed this cache variable.
So I’m at least wondering if this difference explains why the CI works and mine doesn’t
I don’t really understand why I have 11.1 sdk there when I’m still on 10.15 … but googling around it might be the latter versions of the command-line-tools for 10.15 did include this. But I noted that the symlink points at 11.1. If I replace that symlink with one pointing to 10.15 then the rootcling works. It also looks as if the other things I am compiling continue to work too (but I may have spoken too soon … still waiting for things to finish compiling).
At this time I can confirm that changing that symlink over has allowed everything to compile and so far ROOT is behaving completely as I would expect it to. It’s still not clear why the symlink was pointing at MacOSX11.1.sdk or even why that’s there in the first place - but I do find it interesting the CI job is using it (and I guess its possible the CI machine doesn’t even have a MacOSX10.15.sdk dir? … but it seems I need it to get other things to compile).
Would be curious to know what others still on macOS 10.15 see in their SDKs directory?..
I had exactly the same problem. In /Library/Developer/CommandLineTools/SDKs I had the two SDKs for 10.15 and 11.1 and the link pointing to MacOSX11.1.sdk. With this setup I ran into the same problems reported here. Already some time ago I had a similar problem which I finally fixed by modifying the flags for the Makefiles.
After changing the link to point to MacOSX10.15.sdk the compilation of ROOT works again as expected. I did not yet test if the change also fix my other compilation problem but I expect so.
Does this also happen if you start the cmake configuration and the build from a completely empty build directory and with no other ROOT installation available in your environment?