Hello,
Perhaps @vvassilev or @pcanal know what can be the difference between those platforms?
PS: afaik cling needs the C++ standard headers
cling may well need the C++ headers, but do TFile, TDirectory, and TNtuple? – this program just reads and writes Root files containing those types of objects. (If objects with other types happen to be present in a Root file being read, they are ignored. There is no other use of Root.)
FYI: I have been building G4beamline with those three Root classes since ~ 2006, and this is the first time Root has needed the compiler headers in order to pass my regression tests. This is also the first time I have used Root v6.x.x.
ROOT v6 is a very different beast from ROOT v5. In particular the new C++ interpreter, Cling, is now based on an actual compiler toolchain. So it could very well be that CINT did not require compiler headers while Cling does. And ROOT I/O (and therefore TFile) depends on the interpreter so if you depend on TFile you depend on those headers too.
This does not explain your situation – CentOS8 should not work so differently from Ubuntu 22.04. However ROOT is only supposed to work on CentOS8 if all dependencies are installed, you can see the list at Dependencies - ROOT . Maybe the barebones Ubuntu 22.04 installation happens to have all required dependencies included while the barebones Centos8 does not?
Cheers,
Enrico
Thanks. My CentOS, Ubuntu, and macOS bare installs certainly do not have g++, cmake, and some of the other dependencies listed; only CentOS fails for my particular use.
I have been using pre-compiled versions of Root, and had to switch from v5 to v6 because the former referenced older versions of system libraries incompatible with my build. It looks like I have to build v5 from source and use that. As long as the format of Root files does not change for those three classes, this should work. Once I’m doing that, perhaps I can select a much earlier version of Root to get a reduced footprint (ancient versions of G4beamline were built with Root v4).
Ah right, actually those are build dependencies, runtime dependencies are a subset of those. E.g. cmake is a build dependency but not a runtime dependency. 
Doesn’t help me, as I need to link with the Root libraries, and that means at run time the program needs to know where they are, so they must be included in my distribution.
I tried to compile v3.10.02, v4.04.02, and v5.34.17 on macOS Catalina. I fixed hundreds of trivial changes (e.g. <iostream.h> => <iostream>), but there remained too many non-trivial errors.
So I implemented a workaround for root_v6.14.06: if the Root initialization fails and takes a SIGSEGV my code prints out a more user-friendly error message and exits. So some users that use Root NTuples will have to install the C++ compiler (other types of NTuples don’t use Root and don’t have this problem).
As you suggest, I tried root-5-34-00-patches. On my Mac I had to change libstdc++ to libc++ throughout, and had to change configure to look in the right place for the mac SDK.
mkdir $HOME/root_v5.34.00
cd root-5-34-00-patches
./configure macosx64 --minimal --prefix=$HOME/root_v5.34.00
make
… many, many files compiled
Generating dictionary core/base/src/G__Base1.cxx…
core/utils/src/rootcint_tmp -cint -f core/base/src/G__Base1.cxx -c … many .h files …
Error: cannot open file “AvailabilityMacros.h” include/RConfig.h:384:
I created an empty include/AvailabilityMacros.h
make
SUCCESS! (ignoring hundreds of warnings)
make install
SUCCESS!
On my Mac I can run this Root build via the command-line, I can link G4beamline with it, and G4beamline passes all its regression tests. It will take longer to build on CentOS and Ubuntu (Windows is delayed).
Thank you very much!
Tom Roberts
I always install ROOT 5 using the ROOTSYS based method described in this old post.
If you prefer to use the “--prefix” method (i.e., the official “Fixed location installation” method), do always remember to add an appropriate “--etcdir” (no need to do it for ROOT 6) and do remember to “unset ROOTSYS” before running configure and make.
After building Root, I build G4beamline. That build links to the ROOTSYS/lib libraries, copies the ROOTSYS tree into the distribution, and sets the executable’s RPATH to “@executable_path/../root/lib;@executable_path/../lib”. The code before Root initialization sets ROOTSYS to the installation’s root directory. So while the build uses --prefix=$ROOTSYS on the build machine, the runtime uses ROOTSYS on the installation machine.
So, you’d better not use “--prefix” at all and “unset ROOTSYS” before configuring and building it (this will safely create an “in-place” ROOT built, which you seem to use later).
Hmmm. I have been using it as I described since 2006 or so. It works. Remember the only use of Root is to read and write Root files containing TNtuple-s.
I want to separate the install directory from the source directory – if they were together that would add over a half-GigaByte to my distribution, roughly doubling its size. I suppose I could delete all the unused stuff, but that’s a complexity I’d rather avoid.
As a test I used the method described here to build root (slightly modified):
Installing ROOT 5 from Source
cd /Where/I/Unpacked/The/Source/Code/Of/root
export ROOTSYS=/Where/I/Want/To/Install/root
./configure macosx64 --minimal
(g)make
(g)make install # may need “sudo”
This works equally well for G4beamline, so I’ll switch to that recommended method (including other OS-s).
Why do you always add “macosx64”? The correct “architecture” should be guessed automatically.
Building from root-5-34-00-patches works on macOS Catalina after making the edits I described earlier.
@pcanal On Ubuntu 22.04 I had to install curl, but then it failed:
/home/tjrob/root-5-34-00-patches/core/newdelete/src/NewDelete.cxx:181:29: error: ISO C++17 does not allow dynamic exception specifications
181 | # define R__THROW_BAD throw(std::bad_alloc)
Doing “make distclean; export CXXFLAGS=-std=C++11; make” did not affect this.
CentOS 8 stream already had curl, and the build succeeded, but “make install” did not install $ROOTSYS/bin/root or the required cmake file (etc/cmake/FindROOT.cmake is the wrong filename).
Bottom line: as I must build on multiple OSs, my attempts to use Root v5 have failed. As the Root v6 distributions are enormous, and require the similarly-enormous C++ compiler, I’m going to omit Root from my next G4beamline distributions. If many users complain, I’ll consider another attempt to use Root. I’ve already spent too much time on this.
It seems that ROOT 5 (as of today) does not support C++17.
However, you can configure a “minimal” ROOT 5 using one of the (make sure you first “export ROOTSYS=/where/you/want/to/install/root”):
./configure --enable-cxx11 --minimal # build using -std=c++11
./configure --enable-cxx14 --minimal # build using -std=c++14 (-std=c++1y)
Then: “make install”
Then, looking at the output of “./configure --help”, I noticed a MacOS X specific flag “--enable-libcxx” (build using libc++, required by clang cxx11 and cxx14 options), which you may need to add.
In your previous post, you mention “FindROOT.cmake”. So, if you later use CMake to build other packages, which use ROOT, then you can configure a “minimal” ROOT 5 using one of the (make sure you first “unset ROOTSYS”):
cmake -Dcxx11=ON -Dminimal=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/where/you/want/to/install/root /where/you/have/the/source/of/root # build using -std=c++11
cmake -Dcxx14=ON -Dminimal=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/where/you/want/to/install/root /where/you/have/the/source/of/root # build using -std=c++14 (-std=c++1y)
Then: “make install”
Again, on MacOS X you may need to add “-Dlibcxx=ON”.
Finally, do remember that if you set the C++ standard when building ROOT, all other packages, which use ROOT, need to be compiled with the same C++ standard.
Your reply inspired me to revisit my decision to not use Root, especially the ability to use cmake to build v5. Unfortunately I was unable to get root-5-34-00-patches to build via cmake on any OS (macOS Catalina, CentOS 8, Ubuntu 22.04), using any compiler standard (c++11, c++14, c++17). This was expedited by having a powerful Mac Pro that can run two 4-core Linux virtual machines and an 8-core native build, all in parallel.
I then realized that I could build with a binary release of root_v6.26.06, and even though it requires the C++ compiler to be installed, any of my users that only use other NTuple formats would not need to install it. And if I did not build with Root, any user that needed to use Root NTuples would have a MUCH bigger and more difficult task than just installing the compiler (which would of course be the first part of the bigger task). On both Linux-s, installing the compiler is a one-line command; on macOS it is a bit more complicated, but not excessively so.
I have now successfully built my new G4beamline release using root_v6.26.06 on macOS Catalina, CentOS 8 Stream, and Ubuntu 22.04. All three builds run all my regression tests on a bare OS install, after installing the C++ compiler (all three need it; I don’t know why I thought earlier that some OSs didn’t).
Once I get this new release out on these three OSs, I’ll start working on Windows 10. Historically, Windows has been considerably more effort than the other three OSs put together (which is why I decided to not include it in this release).
Thank you all for your help!
For test purposes, I have actually built a “minimal” ROOT 5 using all four methods from my previous post (“configure” and “CMake” with “cxx11” and “cxx14”) on a Ubuntu 22.04 / x86_64 / GCC 11.2.0.
Going for ROOT 6 is a good decision, especially if people need to use it afterward.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.