Building ROOT in STAR

How to build ROOT at BNL and other sites (support documentation)

Some of the above help is similar than what you will find in the PDSF page mentioned above.
Older help version could be found from the revision tab.

ATTENTION

• BEWARE that the target for 64 bit machine is specific to your platform. We use linuxx8664gcc at BNL.
   
• Several patches are available for this revision (see at the bottom as usual). All sources were repackages in Additional software components as root_v5.34.30_2-star.source.tar.gz  (this revision was last made on 2014/06/25). Taking the repacked tar ball is the preffered and recomended approach. Alternatively, you may download the root code from root.cern.ch (the source tar balls are available on their site) but extra steps/actions noted in orange below are needed.
   
• This revision supports Qt4 in its latest incarnation i.e. qt-everywhere-opensource-src-4.8.7 (see Additional software components for more information) - qt 4.4 was left for use for SL5.3
   
• We substantially dropped several OS support since the previous release and this still applies to 5.34.09 i.e.:
  • cygwin not tested at all
  • Mac OSX not tested
  • Solaris and True64 are no longer available to us as build platform and hence, we cannot conclude
  • Linux revisions prior to 5.3 (Boron) are no longer supported.
     
• Only Pythia6 is supported in this version (and is default)

The build

The build is in several steps ; we will assume for this example that we are building root version 5.22.00 ; the % sign is used for the Unix prompt.

1. Go to the $ROOT directory, create a directory named after the version i.e. 5.22.00,  and unpack the tar ball using
   
   % cd $ROOT
   % mkdir 5.34.30_2
   % cd 5.34.30_2
   % setenv ROOTB `pwd`
   
   One note : the ROOTB environment variable will be used throughout this help but is not used by the STAR environment. It only serves the purpose of finding back easily the base tree for the ROOT version you are trying to install.
   
   If you are a STAR user, you can also find a copy of the package in AFS at the location
   /afs/rhic/star/common/General/Sources/  (again, this is the reocmmended approach to avoid extra complications).
   % tar -xzf root_v5.34.30_2-star.source.tar.gz
   
   Remember to remove the archive tar.gz file after unpacking. It is not helpful to keep it around.
   ALL required files (including the STAR specific configurations) are part of our repackaged sources. Starting from ROOT 5.34, no other means are recommended (you may still download the original codes from the ROOT Web site but the STAR specific configs and patches will not be present).
    
2. The structure is not ready ... yet ... You still have to create the OS dependent tree structure we use to allow concurrent platform support in addition of the two layers (with debugging, without debugging information). This is done in a one-does-it-all script.
   
   % $STAR/mgr/MakeRootDir.pl
   
   This command needs to be executed ONCE on EACH supported platform.
   IMPORTANT NOTE: $STAR environment variable needs to be defined here but it case it is not, the latest version available in /afs/rhic.bnl.gov/star/packages/dev/mgr is the safest to use (because it is the latest available). You need to access this script from the AFS path (or make a local copy) if you start building a site from scratch as well (ROOT needs to be installed before $STAR).
    
3. The next step will give an example on how to build it under the linux platform. The above assumes that root is installed in AFS (to make it generic) and that .@sys allows to separate the OS/compiler flavors (which is the case, but not valid for off-site NFS resident tree structure where you will have to specifically use .$STAR_HOST_SYS instead of .@sys ).
   
   % cd $ROOTB/.$STAR_HOST_SYS/rootdeb
   % setenv ROOTSYS `pwd`
   % $STAR/mgr/fixrootmk -unlink
   % ./configure linux --build=debug ... remaining options ... +
   
   % cd $ROOTB/.$STAR_HOST_SYS/root
   % setenv ROOTSYS `pwd`
   % $STAR/mgr/fixrootmk -unlink
   % ./configure linux  ... remaining options ... +
   
   The above examples are both building the standard root distribution and option. This IS NOT what we are using in STAR and the above table shows the default options currently in use. You MUST of course add the --build=debug flag where appropriate as shown above while using that table (i.e. the main point of the two commands as shown is that the rootdeb tree is build with the configure command --build=debug while the optimized version is not).
   
   Notes:
   1. You MUST issue a similar command on ALL platform you are supporting before proceeding to the next step.
   2. You need to run ./configure ONCE only. In case of any further updates, you should NOT repeat this action.
      
    
4. Execute the following script before compiling
   % $STAR/mgr/fixrootmk
   This will check the configuration file for special tags (in the old versions, it would check and fix CERNLIB for example).
   Note that the same command prior with -unlink moved the system.rootrc aside before the configure and make local copies of some of the files which should not be shared between multiple-platforms. At the end of compilation, we will ask you to execute the script again to re-install the system.rootrc and similar files (i.e. make use of the global one for all platforms).
   
   
5. Now we are ready to compile. To do this, simply use the below sequence where you have configured the package.
   % gmake
   
   Notes:
   1. the gmake step may display messages like No such file or directory .
      Please, ignore since this is normal and will trigger the proper directory tree creation.
   2. All is compiled AND INSTALLED. There is NO NEED to use make install.
   3. For those compiling on AFS, if gmake (or make) keeps calling the reconfigure script over and over again, you have two solutions. Either 'sleep 1 && touch Makefile'  and type make again or use 'make --assume-new=Makefile'. The former will reset the Makefile timestamp to a second later of the last command executed and the later tell make to consider the timestamp of the Makefile file as if it has just been modified. You may also try a 'make clean' and try again.
    
6. As noted in a previous step, at the end, finalize the build by doing
   % $STAR/mgr/fixrootmk -fix
   
   and at least once
   
   % cd $ROOT
   % test -e 5.34.30 && rm -f 5.34.09 && ln -s 5.34.09_1 ./5.34.09
   
   This last command link your current build tree to the official 5.34.09. If you had a previous patch level version, it will be replaced at that stage and the new build will become active. There should be NO need to rebuild root4star for incremental patch levels.
   You are now done.

Table of options

Notes:

1. You should use $OPTSTAR at remote sites having a local /opt/star and $XOPTSTAR if you provide support over AFS.
2. If you build Python support, please refer to You do not have access to view this node for quick tests to see if it works
3. To enable the build with QT4, you MUST define QTROOT to point to the QT4 directory prior to executing the configure script (the build will oherwise be silent on missing it)
4. For SL5.3, this version of ROOT was built with the additional option --enable-builtin-pcre
5. If you intend to build ROOT with another compiler revision, ad the options --with-cc=`which gcc` --with-cxx=`which g++`.
6. --disable-xrootd should be used wherever you do not have Xrootd support (or do not need it)
7. If you change the Python verison on your system, note that the PyROOT binding will need to be remade. However, this will not be as easy as typing make as specific version-keyed includes will be needed. You may however try something like
   % modify python2.4 python2.7 ./config/Makefile.config
   in the $ROOTSYS directory and type make afterward (this will work). Ultimately, you may also re-build in your private area and
   % cp -fp lib/libPyROOT.so $ROOTSYS/lib
   % cp -fp lib/ROOT.py* $ROOTSYS/lib
   i.e. no need to compile in-place.

List of updated files 

The below list is provided for convenience but you should send a note if you note ANY differences from this list and what was packaged for use by remote sites. In the below,  A=added, P=patched, U=updated:

     
P    root/cint/cint/inc/G__ci.h
P    root/math/vc/Module.mk
P    root/bindings/pyroot/Module.mk

Typical patched codes The following codes are tweaked