Home | News | Documentation | Download

Build Problem with XROOTD on ROOT v6-22-00

ROOT Version: v6-22-00
Platform: Linux xubuntu 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Compiler: gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0


Having successfully built ROOT with Python3 before, I updated my repository:

git pull origin master
git checkout tags/v6-22-00

git status showed:

HEAD detached at v6-22-00
nothing to commit, working tree clean

I have none of the “optional” dependencies installed but have all the essential dependencies:

> apt list --installed dpkg-dev cmake g++ gcc binutils libx11-dev libxpm-dev libxft-dev libxext-dev python
binutils/focal,now 2.34-6ubuntu1 amd64 [installed]
cmake/focal,now 3.16.3-1ubuntu1 amd64 [installed]
dpkg-dev/focal,focal,now 1.19.7ubuntu3 all [installed,automatic]
g++/focal,now 4:9.3.0-1ubuntu2 amd64 [installed,automatic]
gcc/focal,now 4:9.3.0-1ubuntu2 amd64 [installed]
libx11-dev/focal,now 2:1.6.9-2ubuntu1 amd64 [installed,automatic]
libxext-dev/focal,now 2:1.3.4-0ubuntu1 amd64 [installed,automatic]
libxft-dev/focal,now 2.3.3-0ubuntu1 amd64 [installed,automatic]
libxpm-dev/focal,now 1:3.5.12-1 amd64 [installed]

Note that there is no listing for python, but python 3 is available:

python3/focal,now 3.8.2-0ubuntu2 amd64 [installed]

Without deleting the cache, cmake --build . stopped at 45%, having completed target Unix:

Built target Unix
make[2]: *** No rule to make target '/[...]/root/core/clingutils/inc/TClingRuntime.h', needed by 'core/G__Core.cxx'. Stop.
make[1]: *** [CMakeFiles/Makefile2:17452: core/CMakeFiles/G__Core.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Presuming this might be a cmake cache problem, I re-generated the build files, after deleting the build directory, using:

cmake -DPYTHON_EXECUTABLE=/usr/bin/python3.8 -DCMAKE_CXX_STANDARD=17 -DCMAKE_INSTALL_PREFIX=/home/[my path]/ ../root

And the result was:

CMake Error at /[...]/build-root-Desktop_Clang-Release/XROOTD-prefix/src/XROOTD-stamp/XROOTD-build-Release.cmake:49 (message):
  Command failed: 2


  See also


make[2]: *** [CMakeFiles/XROOTD.dir/build.make:113: XROOTD-prefix/src/XROOTD-stamp/XROOTD-build] Error 1
make[1]: *** [CMakeFiles/Makefile2:7144: CMakeFiles/XROOTD.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Note that ‘[…]’ is my shorthand for the path to my home directory.

XROOTD-build-out.log shows that the build stops at:

Scanning dependencies of target XrdSecProt-4
[ 89%] Building CXX object src/CMakeFiles/XrdSecProt-4.dir/XrdSec/XrdSecProtect.cc.o

And XROOTD-build-err.log shows:

[I] No git repository info found. Trying to interpret VERSION_INFO
[I] src/XrdVersion.hh successfully generated
/home/[...]/build-root-Desktop_Clang-Release/XROOTD-prefix/src/XROOTD/src/XrdSec/XrdSecProtect.cc:42:10: fatal error: openssl/sha.h: No such file or directory
   42 | #include "openssl/sha.h"
      |          ^~~~~~~~~~~~~~~
compilation terminated.
make[5]: *** [src/CMakeFiles/XrdSecProt-4.dir/build.make:63: src/CMakeFiles/XrdSecProt-4.dir/XrdSec/XrdSecProtect.cc.o] Error 1
make[4]: *** [CMakeFiles/Makefile2:1539: src/CMakeFiles/XrdSecProt-4.dir/all] Error 2
make[3]: *** [Makefile:130: all] Error 2

All of which leads me wonder:

  • Have I missed something obvious in my update sequence?
  • Would this error suggest that there is an undeclared dependency of XROOTD on OpenSSL?
  • Even if the problem with XROOTD is fixed, will the problem building G__Core.cxx recur?

FWIW: the cmake command line works fine for v6-20-00, but the initial build order is different.

Many thanks in advance for any help you can give…


It appears to me that you have missing openssl-dev (or libssl-dev) package. There may be more.

Did you check whether all the required dependencies (including the most common dependencies) are already installed properly?

You can also try -Druntime_cxxmodules=OFF and enable those optional packages which you want.

I suspect you are correct - there is an unmet dependency on openssl.

My post indicated that I had installed all the required dependences for v6-22-00. If there were one missing, I would expect cmake to detect the problem and report an error, which was not the case.

I was deliberately building without the optional dependencies - of which openssl-dev is one, indicating to me that there might be a fault in the build process but before posting a spurious bug report, I wanted to check that I’d not missed anything.

1 Like

Although “you” were building ROOT without any optional dependencies, ROOT is built with ssl option (which requires OpenSSL) by default. Please check build options carefully.

I suggest you to install most common optional packages, and then give the installation a fresh try, preferably by deleting all the content of your build directory for a clean installation.

Alternatively, you may try "-Dminimal=ON".

I hope this helps. Please let me know.

1 Like

I created https://sft.its.cern.ch/jira/browse/ROOT-10906 to track this issue – there is a bit more latency in the summer months, but we’ll get to this as soon as possible.

In the meanwhile, if you could confirm that installing the openssl headers fixes your build problems it would help a lot.


Many thanks.

Not a problem regarding latency! I will only have an opportunity to test the build toward the end of this week.

The problem is related to commit 506e2232a3. Between releases, the default behavior changed. Before, the option xrootd was disabled due to XRootD not being found, and now the builtin_xrootd option is turned ON instead, which requires openssl-dev. You can either install openssl-dev and keep support for XRootD enabled, or add -Dxrootd=OFF -Dbuiltin_xrootd=OFF to your build options to recover the previous behavior.


Thanks for being patient! Using sudo apt-get install libssl-dev solves the problem of xrootd not building. Sadly at 45%, the build grinds to a halt, reporting:

Scanning dependencies of target Unix
[ 45%] Building CXX object core/unix/CMakeFiles/Unix.dir/src/TUnixSystem.cxx.o
[ 45%] Built target Unix
[ 45%] Generating G__Core.cxx, ../lib/Core.pcm
/home/[...]/build-root-Desktop_gcc-6-22-Release/include/module.modulemap:20:42: error: header 'RConfigure.h' not found
  module "RConfigure.h" { textual header "RConfigure.h" export * }
/home/[...]/build-root-Desktop_gcc-6-22-Release/include/RtypesCore.h:25:10: note: submodule of top-level module 'ROOT_Config' implicitly imported here
#include "DllImport.h"
/home/[...]/build-root-Desktop_gcc-6-22-Release/include/RtypesCore.h:117:1: error: unknown type name 'R__EXTERN'
R__EXTERN Int_t gDebug;
/home/[...]/build-root-Desktop_gcc-6-22-Release/include/RtypesCore.h:117:16: error: expected ';' after top level declarator
R__EXTERN Int_t gDebug;
In file included from input_line_5:1:
/home/[...]/build-root-Desktop_gcc-6-22-Release/include/Rtypes.h:23:10: fatal error: could not build module 'ROOT_Rtypes'
#include "RtypesCore.h"
While building module 'Core':
While building module 'ROOT_Foundation_C' imported from /home/[...]/build-root-Desktop_gcc-6-22-Release/include/Rtypes.h:26:
In file included from <module-includes>:1:
/home/marvin/Documents/build-root-Desktop_gcc-6-22-Release/include/ThreadLocalStorage.h:61:10: fatal error: could not build module 'ROOT_Rtypes'
#include "RtypesCore.h"
While building module 'Core':
While building module 'ROOT_Foundation_Stage1_NoRTTI' imported from /home/[...]/build-root-Desktop_gcc-6-22-Release/include/Rtypes.h:193:
In file included from <module-includes>:5:
/home/[...]/build-root-Desktop_gcc-6-22-Release/include/TIsAProxy.h:16:10: fatal error: could not build module 'ROOT_Rtypes'
#include "RtypesCore.h"
Error: Error loading the default header files.
make[2]: *** [core/CMakeFiles/G__Core.dir/build.make:462: core/G__Core.cxx] Error 1
make[1]: *** [CMakeFiles/Makefile2:17809: core/CMakeFiles/G__Core.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Any thoughts on what to try to fix this? (Note: [...] represents the path to my home directory.)

Apart from using a new build directory and installing libssl-devel, the process was the same as reported in my first post. The output from cmake is available in a text file here.

Many thanks


Try with -Druntime_cxxmodules=OFF.

Thank you for all your help!

The build completed without problem and initial tests of ROOT v6-22-00 show that it is working as expected.

I deleted the build directory and removed libssl-dev, switched off xrootd, builtin_xrootd and runtime_cxxmodules. I noticed that with this configuration, OpenSSL was the first thing to be built! When I next have time, I will try -Dminimal=ON and report back on what happens.

Please forgive my misunderstanding earlier: I had thought that once all the required libraries were installed, ROOT would build anything else it needed or report a missing component at the configuration stage.

I am investigating whether ROOT works as a minimalist system for students to use to learn C++ by creating ‘simple’ physical models and drawing graphs of the resulting data.

Indeed, the fact it did not go like that is a bug.

In case it can be useful, for ease of installation on the part of students ROOT is available in docker containers or via package managers for Linux and MacOS, see here.


Enrico: thank you for the update and your suggestions.

The MacOs and Linux binary versions are noted and welcome. I have also to support Windows users who form the majority of my students.

Would I be right to assume that Conda ROOT support for Windows will only be activated when the Windows binaries move out of ‘preview’ mode? If so, is there a timeline for this?


@chrisburr can correct me if I’m wrong, I think the problem with releasing conda ROOT packages for windows is that our windows (alpha) releases are 32-bit only.

For your students with a windows computer: it should be fairly straightforward to use the Windows Subsystem for Linux, that’s basically Ubuntu installed as a Windows app. There are a few posts on the forum about users’ experience with it, it’s mostly positive.

About a timeline for a “1.0” Windows ROOT release, that’s a question for @bellenot.



Correct. The current Windows binaries are 32 bit only.

I hope after the llvm/clang upgrade (whenever that will happen), even if the current status is very close to be stable…

Cheers, Bertrand.