unable to build v6-26-00 with clang 13.0.1

[cgleggett]

Describe the bug

building root v6-26-00 with clang 13.0.1 fails with many errors. I have tried with both gcc8.4 and gcc11.2 toolchains for clang. This is on a centos7 system. The cmake (3.22.2) configuration step was:

cmake -DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_EXTENSIONS=Off -GNinja ../src

Is this expected behavior? If so, what version of clang is supported for building root?

If desired, I will attach the build errors.

[hahnjo]

Compiling with Clang 13 on CentOS 8 works fine. If you write "gcc8.4 and gcc11.2 toolchains for clang", does this include libstdc++? The system-provided one on CentOS 7 (from GCC 4.8) is too old for C++14, which is now required since ROOT 6.26.

Yes, build errors would certainly help to determine which parts cause problems.

[cgleggett]

see attached log. this is after running ninja as far as it will go, then re-running it to just capture the errors.

root_bld_err.txt

this is from building with clang 13.0.1 that was built with the gcc 8.4 toolchain. It was built with -DLLVM_ENABLE_PROJECTS=clang

[cgleggett]

here is the cmake configuration log. system was setup with

> module list
  1) cmake/3.22.2         2) gcc/8.4.0            3) clang/13.0.1-gcc84

CC and CXX env vars are set to the clang_wrapper that does ${CLANG_ROOT}/bin/clang --gcc-toolchain=/opt/gcc/8.4.0

cmake.log

[hahnjo]

What is happening here is that your build pulls in header files from Clang 13.0.1, instead of using those bundled with ROOT:

/opt/clang/13.0.1-gcc84/include/llvm/ADT/StringRef.h:272:14: note: explicit conversion function is not a candidate
    explicit operator std::string() const { return str(); }
             ^

In

root/interpreter/llvm/src/include/llvm/ADT/StringRef.h

Lines 246 to 248 in c4175cb

	operator std::string() const {
	return str();
	}

the conversion operator isn't explicit yet and the code works.

Do your compiler wrappers maybe also add arguments or set environment variables that change the include path?

[cgleggett]

this is the compiler wrapper:

#!/bin/bash
GCC_DIR=`which gcc | sed "s/\/bin\/gcc$//"`
${CLANG_ROOT}/bin/clang++ --gcc-toolchain=${GCC_DIR} "${@}"

should I set CXX to just /opt/clang/13.0.1-gcc84/bin/clang++ ?

[hahnjo]

You could try that, but I'm not sure this will change a lot. It could also be that your clang/13.0.1-gcc84 module sets some weird variables. Could you try a clang++ -v on a dummy C++ file to see what directories end up in the search path?

[cgleggett]

clang++ -v output is:

clang version 13.0.1 (https://github.com/llvm/llvm-project.git 75e33f71c2dae584b13a7d1186ae0a038ba98838)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/clang/13.0.1-gcc84/bin
Found candidate GCC installation: /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0
Selected GCC installation: /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
Found HIP installation: /opt/rocm, version 4.4.21432
 "/bld4/opt/clang/13.0.1-gcc84/bin/clang-13" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -main-file-name a.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/tmp -resource-dir /bld4/opt/clang/13.0.1-gcc84/lib/clang/13.0.1 -I/opt/clang/13.0.1-gcc84/include -internal-isystem /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../include/c++/8.4.0 -internal-isystem /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../include/c++/8.4.0/x86_64-pc-linux-gnu -internal-isystem /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../include/c++/8.4.0/backward -internal-isystem /bld4/opt/clang/13.0.1-gcc84/lib/clang/13.0.1/include -internal-isystem /usr/local/include -internal-isystem /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../x86_64-pc-linux-gnu/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir=/tmp -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/a-410af6.o -x c++ a.cpp
clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../x86_64-pc-linux-gnu/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/clang/13.0.1-gcc84/include
 /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../include/c++/8.4.0
 /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../include/c++/8.4.0/x86_64-pc-linux-gnu
 /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../include/c++/8.4.0/backward
 /bld4/opt/clang/13.0.1-gcc84/lib/clang/13.0.1/include
 /usr/local/include
 /usr/include
End of search list.
 "/usr/bin/ld" --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /lib/../lib64/crt1.o /lib/../lib64/crti.o /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/crtbegin.o -L/opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0 -L/opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/bld4/opt/clang/13.0.1-gcc84/bin/../lib -L/lib -L/usr/lib -L/opt/clang/13.0.1-gcc84/lib /tmp/a-410af6.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /opt/gcc/8.4.0/lib/gcc/x86_64-pc-linux-gnu/8.4.0/crtend.o /lib/../lib64/crtn.o

[hahnjo]

Ok, as expected /opt/clang/13.0.1-gcc84/include is way too early. Do you maybe have this in your CPATH or CPLUS_INCLUDE_PATH variable? If so, I fear you'll have to unset that for building ROOT...

[cgleggett]

indeed, the modulefile does:

prepend-path {CPATH} "${CLANGROOT}/include"

I'll try again with it unset.

[cgleggett]

removing the CPATH env var did the trick.

thanks!