Maintained by: the ROOT team and collaborators
Where to get help: the ROOT forum
latest
->6.26.02-ubuntu22.04
6.26.02-ubuntu20.04
,6.26.00-ubuntu20.04
,6.24.06-ubuntu20.04
,6.24.02-ubuntu20.04
,6.24.00-ubuntu20.04
,6.22.08-ubuntu20.04
,6.22.06-ubuntu20.04
,6.22.02-ubuntu20.04
,6.22.00-ubuntu20.04
,6.20.08-ubuntu20.04
6.26.00-conda
,6.24.06-conda
,6.24.02-conda
,6.24.00-conda
,6.22.08-conda
,6.22.06-conda
,6.22.02-conda
,6.22.00-conda
6.26.00-arch
,6.24.06-arch
,6.24.02-arch
,6.24.00-arch
,6.22.06-arch
,6.22.02-arch
,6.22.00-arch
,6.20.06-arch
6.24.06-fedora35
6.22.08-fedora34
6.22.06-fedora33
6.22.02-fedora32
,6.22.00-fedora32
,6.20.06-fedora32
6.24.06-centos7
,6.22.08-centos7
,6.22.02-centos7
,6.22.00-centos7
It is important to compile ROOT applications with the same C++ standard as ROOT itself was compiled with. Different images provide ROOT installations built with different C++ standards. Here is a breakdown by tag:
latest
,ubuntu22.04
: C++17 supportubuntu22.04
(starting from ROOT 6.24): C+14arch
,conda
,fedora34
,fedora35
: C++17fedora32
,fedora33
: C++14ubuntu20.04
(up to ROOT 6.22),centos7
: C++11
The ROOT team provides several Docker images. In order to run containers, you must have Docker installed. You can start a container by running the following command in your terminal which will start the latest stable release of ROOT:
docker run --rm -it rootproject/root
Note that the --rm
flag tells Docker to remove the container, together with its data, once it is shut down. In order to persist data, it is recommended to mount a directory on the container. For example, to mount your home directory on Linux and Mac, run:
docker run --rm -it -v ~:/userhome --user $(id -u) rootproject/root
On Windows, you have to specify the full path to your user directory:
docker run --rm -it -v C:\\Users\\Username:/userhome rootproject/root
The -v
option tells Docker to mount the home directory (~
) to /userhome
in the container. --user $(id -u)
signs us in with the same userid as in the host in order to allow reading/writing to the mounted directory. This is not necessary on Windows. Mac and Windows users does however have to mark the drives or areas they want to mount as shared in the Docker application under settings.
Configuring Docker for Windows Shared Drives / Volume Mounting with AD More about mounting host directories in the container.
To use graphics, make sure you are in an X11 session and run the following command:
docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --rm -it --user $(id -u) rootproject/root root
On some platforms (e.g., Arch Linux) connections to the X server must be allowed explicitly by executing xhost local:root
or an equivalent command (see e.g. this page for more information on xhost
and its possible security implications).
To use graphics on OSX, make sure XQuarz is installed. After installing, open XQuartz, and go to XQuartz, Preferences, select the Security tab, and tick the box "Allow connections from network clients". Then exit XQuarz. Afterwards, open a terminal and run the following commands:
ip=$(ifconfig en0 | grep inet | awk '$1=="inet" {print $2}')
This will grab your IP address on the local network. Run echo $ip
to make sure it was successfull. If nothing is displayed, replace en0
with en1
or a higher number in the command.
xhost + $ip
This will start XQuartz and whitelist your local IP address. Finally, you can start up ROOT with the following command:
docker run --rm -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=$ip:0 rootproject/root root
To enable graphics, you must have Xming installed. Make sure Xming is whitelisted in the Windows firewall when prompted. After installing Xming, white-list the IP-address of the Docker containers in Xming by running the following command in PowerShell as administrator:
Add-Content 'C:\Program Files (x86)\Xming\X0.hosts' "`r`n10.0.75.2"
Restart Xming and start the container with the following command:
docker run --rm -it -e DISPLAY=10.0.75.1:0 rootproject/root
See GitHub for example Dockerfiles.
Even though for each image we link to the Dockerfile that produced it, in several cases running that same exact Dockerfile will not result in an image identical to the one we offer. Sometimes it will even result in an image with a more recent ROOT version: this is the case for images based on rolling Linux distributions such as Arch, for example.
The *_from_source
recipes, on the other hand, are expected to be fully reproducible.