Some more info on the fresh new RDataFrame interface in this post.
1 Like
@uzair90 Please try again with GCC 4.8.5 or newer. ROOT needs full support for C++11, and GCC 4.8.0 does not have it yet.
Edit: This specific problem may actually be a problem with dependencies in CMake, however (see ROOT-9478).
And Ubuntu 16.04 comes with GCC 5.3.
Hello,
I am also having trouble with root installation. This is the error I am getting:
[ 88%] Generating G__ROOTVecOps.cxx, ../../lib/libROOTVecOps_rdict.pcm, ../../lib/libROOTVecOps.rootmap
In file included from input_line_12:7:
/home/arka/Root6_Build/include/ROOT/RVec.hxx:36:10: fatal error: 'vdt/vdtMath.h' file not found
#include <vdt/vdtMath.h>
^~~~~~~~~~~~~~~
Error: /home/arka/Root6_Build/bin/rootcling: compilation failure (/home/arka/Root6_Build/lib/libROOTVecOpse1583191ba_dictUmbrella.h)
math/vecops/CMakeFiles/G__ROOTVecOps.dir/build.make:69: recipe for target 'math/vecops/G__ROOTVecOps.cxx' failed
make[2]: *** [math/vecops/G__ROOTVecOps.cxx] Error 1
CMakeFiles/Makefile2:20851: recipe for target 'math/vecops/CMakeFiles/G__ROOTVecOps.dir/all' failed
make[1]: *** [math/vecops/CMakeFiles/G__ROOTVecOps.dir/all] Error 2
Makefile:151: recipe for target 'all' failed
make: *** [all] Error 2
This is my gcc version ubuntu 18.04:
gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
How do I fix this issue?
Thanks,
Arka
Hi Arka,
see Guilherme’s comment in the linked Jira ticket: Loading...
you should add the line
set_property(GLOBAL APPEND PROPERTY ROOT_BUILTIN_TARGETS VDT)right after line
set(vdt ON CACHE BOOL "" FORCE)in filecmake/modules/SearchInstalledSoftware.cmake.
Cheers, Axel.
Alternatively, without making any change to ROOT, you can do (in the build directory):
$ cmake --build . --target VDT
$ cmake --build .
The problem is that CMake fails to add a dependency on VDT, so it is not built early enough.
This is being fixed here: https://github.com/root-project/root/pull/2205.
1 Like
The problem is fixed. Thank you very much.
It’s also fixed on the master and 6.14 branches as well, so when 6.14/02 is released, this will not be a problem anymore. Cheers,
Hi,
Will there be a binary distribution of v6.14 compatible with SLC 6.9? This doesnt seem to be the case at the moment. Hence one cannot set it up on lxplus - SLC 6.9 from CVMFS either.
And trying to compile ROOT v6.14 on SLC 6.9 runs into other problems, such as requiring cmake version 3.4.3 which doesnt seem to be available for SLC 6.
Any suggestions would be very welcome.
Thanks
Halil
Hi
I am new to jupyter
can we install python 2 and 3 on same system through Jupyter
You could simply log on to lxplus7.cern.ch. Would that be a solution for you?
Hi priyanka_120993, could you open a new topic for this?
Axel
Hi Axel,
Sure, that works in principle. However bulk of the input samples I would like to work with are not stored on lxplus but in other machines where the OS is still SLC 6 (probably a fairly common situation). Is there a fundamental reason why an SLC 6.9 binary is difficult to centrally provide? I understand that CentOS 7 is the next step but this will really save a lot of hassle until the transition is complete. Normally I wouldnt mind not having the latest version of ROOT, but this one surely deserves an update 
Thanks
Halil
Hi Halil,
SLC6’s compiler (GCC4.4!) is too old to build ROOT - GCC 4.4.0 is from 2009! Use LCG releases to create a custom environment (but then e.g. emacs is broken etc), or simply log on to lxplus7 where the compiler is old, too, but just recent enough.
Axel.
Hi Axel,
I see, I do get the general idea that lxplus7 is the recommendation from ROOT side.
But given than CentOS 7 is not the industry standard yet, neither in lxplus nor in fnal lpc (not even available on most nodes for batch processing etc), is there any possibility of accommodating this transitional period from the ROOT end? Or is it simply not possible to compile ROOT in SLC6.9? If it is possible, I would really appreciate a bit more guidance or a recipe on that front.
Thanks
Halil
Hi,
- CentOS7 is the industry standard. It’s from 2014, i.e. four years old.
- CERN IT will switch the lxplus alias to CentOS7 next summer https://indico.cern.ch/event/676324/contributions/2953740/attachments/1649534/2637504/CERN_Site_Report_-_HEPiX_Spring_2018.pdf
- The SLC6 compiler is too old to build ROOT. I can not. Doesn’t compile.
- You can build your own compiler on lxplus, but then you need to build all dependencies, too. That’s what “LCG releases” in
/cvmfs/sft.cern.ch/provide; the newest one (containing ROOT v6.14/00) isn’t out yet, might take a couple of weeks. We’re not doing that; we (the ROOT team) recommends to use an OS that is recent enough to support the newest ROOT. I.e. younger than 9 years…
I’m curious - what’s stopping you from using lxplus7? You can access the same files from lxplus and lxplus7, no difference.
Cheers, Axel.
-
The LCG dev4 release has 6.14. Use
source /cvmfs/sft.cern.ch/lcg/views/dev4/latest/x86_64-slc6-gcc7-opt/setup.sh -
@Axel, do you have any idea why it’s taking so long to switch to CentOS 7? At this rate, CentsOS 8 will be out by the time the grid supports CentOS 7.
I’m curious - what’s stopping you from using lxplus7? You can access the same files from lxplus and lxplus7, no difference.
@hsaka is probably using an SLC6 only Tier 3.
@hsaka depending on what you use from ROOT (it’s a large toolkit/framework!) you may (or may not) have a look at go-hep/rootio that can read ROOT TFile, TTrees and TH{1,2}x.
Also, as it’s pure Go, you can compile to completely static binaries (for Linux, Windows, macOS, FreeBSD, …) w/o caring for the target toolchain: Go binaries compiled on, say, Ubuntu-14.10 will happily run on Centos7 or SLC6.
the target system won’t even need to have the Go toolchain installed.
no strings attached
No strings attached and not a lot of features either 
@sbinet - I’m all in favor of good competition and I don’t mind you using the forum to advocate for your software, but please stay within reason. You have posted to a topic that announces ROOT 6.14/00. I do not find your comment helpful in this context, as it doesn’t address an actual technical issue with an alternative implementation but is a blanket “use mine instead”. Thank you for your understanding, please consider re-wording your comment. (Else I will go shopping for a couple of trolls that post “use R”, “use Mathematica”, “use Octave”, “use python”, “use Perl”, “use Excel” to every ROOT post and we can close the forum.)
I do not find your comment helpful in this context, as it doesn’t address an actual technical issue with an alternative implementation
I am sorry you felt it that way.
I am always very careful not to be too pushy (that’s subjective), not to oversell Go (I also mention uproot (especially b/c I find it a vindication of the approach taken by go-hep/rootio) and do help people with regular C++/ROOT or PyROOT).
I am also always very careful to mention go-hep/rootio only when after somebody from the ROOT team has answered and when that answer isn’t completely satisfying (that’s somewhat less subjective a statement).
in the case at hand, the OP may not be able to switch from SLC6 to Centos7 for many $REASONS.
how is this not an actual technical issue?
I’ve argumented and explained why it could be a good fit (with a foreword caveat) for the particular situation.
In my book, that’s far from being a troll.
not a lot of features either
true. (at least wrt ROOT I/O. I’d disagree wrt being able to perform physics analyses, though.)
still, that stings a bit. (while I have a few users, I am the only one working on rootio, and only 20%. and most probably not as clever as the ROOT team.)
but do tell me what I need to reword and I’ll gladly comply.