I am writing a software tool for my working group that has the software
requirements of:
ROOT v6.09
Python 2.7 (or greater)
PyROOT
root_numpy
From the ROOT 6.09/02 release notes it seems that there was an intentional move to release only a CentOS 7 version on CVMFS. I assume this is in preparation for CERN transitioning to SL7 in the near(ish) future.
My tool relies on TRatioPlot and as my group wants to be able to use it not only on lxplus7.cern.ch but also on different Tier-2 and Tier-3 sites need it to be CVMFS based. However, as all of those sites aren’t running SL7 at the moment it seems that these two constraints (ROOT 6.09 and CVMFS on SL6) are incompatible. Is there any known way to achieve this? Or am I going to have to just do without TRatioPlot for the next few years?
The problem with SLC6 is that its compiler is really old - people had to set up a different compiler, and that’s always a mess. Now you can just run ROOT, as is.
For SLC6 you can use the LCG releases which package a whole lot of dependencies (including the compiler). I thought that this is set up like this:
-bash: /cvmfs/sft.cern.ch/lcg/releases/LCG_88/ROOT/6.08.06/x86_64-slc6-gcc62-opt/bin/root-config: /cvmfs/sft.cern.ch/lcg/releases/curl/7.19.7-dde5e/x86_64-slc6-gcc62-opt/bin/en: bad interpreter: No such file or directory
I have contacted the LCG people, I’ll let you know…
Also, I’m concerned that even this might not work, as there was a seg fault inducing bug when using TRatioPlot with PyROOT (that I assumed appeared in ROOT 6.08). This was fixed in ROOT 6.09, but I need to check to see if it was also corrected in ROOT 6.08.
So it can be seen that this is a problem because lcgenv is set using ls instead of using find. I have aliased ls to be alias ls='ls -lhBF --color=auto'. Removing this fixes the problem. Many thanks, @mato, for the suggestion.
Given that aliasing ls is fairly common, can we either have a warning RE: this at the top of these scripts, or just using find by something along the lines of (a more elegant form of)
function getFullFilePath () {
if [[ "$#" -eq 2 ]]; then
echo "$(readlink -f "$(find $2 -iname $1)")"
else echo "$(readlink -f "$(find . -iname $1)")"
fi
}
function getFullDirPath () {
pth="$(getFullFilePath $1)"
if [[ -z "${pth}" ]]; then
echo ""
else echo "$(dirname "${pth}")"
fi
}
I understand that this is another issue and that this really isn’t the place to discuss it, but I don’t think it is that crazy to alias ls.
Good that the origin of the problem is understood. I 'll pass the issue to the author of the script to improve it.
Created https://sft.its.cern.ch/jira/browse/SPI-968
I think a simple replacement of ls by \ls should solve this particular problem.
(The dev3 master snapshot causes a segfault for some reason, but I can worry about that later).
If I’m going to start using this in my tool, I have a question RE: the nightlies. I don’t know how the nightlies actually work, so If I want to always in the future be sourcing from the branch of v6.08 with the latest patches then will that path always work? Given that it has a day of the week in the path name I assume not. Is that correct? Or do I not understand the path naming conventions here?
That’s correct - we don’t have a “latest” link to figure out which day to use. Shall I ask for that?
But either way, if you build software on top, changing the ROOT version underneath is probably not a good idea. We do have binary incompatible changes from time to time
Yeah, @Axel if it is possible to get that link I think it would be helpful.
You make a good point. However, if I’ve designed most of the code to be able to deal with ROOT v6.09 safely then if I’m just using the latest patched version of ROOT v6.08 then as long as a patch to TRatioPlot doesn’t cause TRatioPlot to self induce a segfault I think I should be okay(?). Or is that horribly naive?
That’s the binary compatibility issue that I was referring to: if we change ROOT from Tue to Wed in a binary incompatible way, your program built against Tuesday’s ROOT would not run anymore on Wednesday.
I.e. no, in general you need to build a dedicated binary of your program for a given ROOT version. Using the v6.08 release series sounds like the right approach.
Okay, thanks for the news. I think I understand what you mean now, however I have one more dumb question about LCG nightlies, if you don’t mind.
You suggested using nightlies for checking that a patch has been integrated. How do I know that a patch that has been applied to the nightlies has also been integrated into the latest version tag? Just by checking to see if the tag has been increased lately?
So for example, if it is currently a Monday and I have reported a bug in ROOT v6.08 and the latest version number in LCG_88 and on Tuesday if I run
We (ROOT) only tag once every month or so. So if it’s not in 6.08/06 but in the nightlies then it will appear in 6.08/08. 6.08/06 is never updated itself; it is superseded by a (possibly binary incompatible, thus the new tag!) 6.08/08.
Now, due to you using lxplus (SLC6) instead of lxplus7 (CC7) you also depend on the LCG releases. I would assume that LCG_89 will then pick up 6.08/08 once we (ROOT) have released it. But maybe LCG_89 gets released earlier - that’s not under our control. But indeed: as soon as we (ROOT) have released 6.08/08 the next LCG release should contain the fix.
Or: log on (and tell your users to log on) to lxplus7 and simply use 6.09/02 from . /cvmfs/sft.cern.ch/lcg/app/releases/ROOT/6.09.02/x86_64-centos7-gcc48-opt/root/bin/thisroot.sh.
Summary:
if you build software on top of ROOT, use releases
if you want simplicity, use lxplus7 (which has a compiler that is reasonably new)
if you want everything provided, use LCG releases - but then you add latency for new ROOT releases.
