I’ve installed ROOT v6.20.04 from source on my Ubuntu 18.04 machine, with no errors. g++ version 7.5.0, cmake version 3.10.2, all ubuntu dependencies are installed.
I’m now trying to compile user c++ code with the root libraries using make, the code is given to me by a collaborator who says it works on their machine (with similar environment).
I get the warning:
Warning in cling::IncrementalParser::CheckABICompatibility():
Possible C++ standard library mismatch, compiled with GLIBCXX ‘20180720’
Extraction of runtime standard library version was: ‘20191114’
I also get 6 errors (the forum won’t let me post more than 2 “links” per post so I’ve removed the error name of the following 5):
Error in TInterpreter::InspectMembers: TClass and cling disagree on the size of the class TListOfEnums, respectively 128 152
TClass and cling disagree on the size of the class THashList, respectively 88 112
TClass and cling disagree on the size of the class TList, respectively 80 104
TClass and cling disagree on the size of the class THashList, respectively 88 112
TClass and cling disagree on the size of the class TList, respectively 80 104
TClass and cling disagree on the size of the class TList, respectively 80 104
Can you use root from the commandline without errors?
Have you upgraded your compiler version since you compiled ROOT?
Can you try installing ROOT via conda or run things inside a ROOT docker container, or on lxplus, or otherwise try reproducing the error with a ROOT version that you have not compiled yourself? (instructions to get ROOT in these different ways can be found here.
I can execute root from command line with no errors. My ~/.bashrc uses: source /home/thomas/ROOT/root-install/bin/thisroot.sh
I compiled this version of root yesterday (24th July) and have not upgraded the compiler version since.
I’ve now installed conda version 4.8.3 and used the ROOT install instructions to setup a conda environment “root-env” with root 6.22.0. This finished with no errors.
I then entered the conda environment with: conda activate root-env
“which root” gave: /home/thomas/miniconda/envs/root-env/bin/root
Typing root in this environment gave multiple warnings and the error:
ERROR in cling::CIFactory::createCI():
resource directory /home/thomas/miniconda/envs/root-env/etc//cling/lib/clang/3.9.0 not found!
error: unable to read PCH file /home/thomas/miniconda/envs/root-env/etc//allDict.cxx.pch: ‘No such file or directory’
fatal error: PCH file ‘/home/thomas/miniconda/envs/root-env/etc//allDict.cxx.pch’ not found
*** Break *** segmentation violation
This again seems to be associated to an error in cling and/or clang, this time in the conda environment.
Edit: The error is correct /home/thomas/miniconda/envs/root-env/etc//cling/lib/clang/3.9.0 does not exist. Instead /home/thomas/miniconda/envs/root-env/etc/cling/lib/clang/5.0.0 exists
Not sure what, but something in your environment is rotten
Can you retry using the conda environment after removing source /home/thomas/ROOT/root-install/bin/thisroot.sh from your .bashrc (and then entering a new shell)? Just to make sure we are not mixing ROOT environments when performing these tests.
If the conda-installed ROOT still errors out after that, please copy-paste the output of the env command when in an environment with a broken ROOT (either conda or home/thomas/ROOT/root-install).
Finally, if you still have the build directory around, please try to give another make and double-check no error messages are printed (I know, I know, just covering all bases).
I removed the source /home/thomas/ROOT/root-install/bin/thisroot.sh from my .bashrc and reentered a new shell. The conda environment gives the same error.
Performing this test I discovered when in my bash environment (not conda) which root gives /usr/local/bin/root
Indeed /usr/local/bin has root executables and a thisroot.sh script. This version of root is an older one I was using before: version 6.10.02. I had installed this version in my home directory but perhaps I also accidentally installed it to /usr/local/bin at the same time. I recall /usr/local/bin is a cmake default location for root, so perhaps I mis-hit enter during the install.
Should these /usr/local/bin files be removed? and if so is there a clean and safe way to do so?
Ah, yes, that ROOT installation in system directories is most likely what’s causing the interference. There is no automatic way to remove those files (work in progress on a root.deb package…).
That installation will have all filesunder /usr/local, but to list what those files are the only way I know of is to build ROOT v6.10 with e.g. -DCMAKE_INSTALL_PREFIX=/some/dir/that/you/will/delete and then check what’s in the install_manifest*.txt, which will list exactly what files make install installed and where.
Or you can just take a look at what’s in /usr/local and most ROOT-specific files should be easy to find.
Sorry about that! It really means that at some point you gave a sudo make install from a ROOT build directory, and that’s not easy to undo unfortunately.
Thank you this rotten environment was the problem!
I went through my /usr/local and removed all root related files I could find. This was mostly just block removing files created on the same date and clearing up any remaining files by cross-checking with the install_manifest.text in my old build directory. Finally I also deleted the old build and install directories (for root v6.10.02) to be safe.
I’m now sourcing my thisroot.sh from my user-built root v6.20.04 code again.
Now my code compiles with the root libraries and runs with no warnings or errors. I will certainly avoid using sudo make install in the future!
