[wshi@login1.summit ~]$ gcc --version
gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[wshi@login1.summit ~]$ cc --version
IBM XL C/C++ for Linux, V16.1.1 (5725-C73, 5765-J13)
Version: 16.01.0001.0010
[wshi@login1.summit ~]$ g++ --version
g++ (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[wshi@login1.summit ~]$ c++ --version
c++ (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[wshi@login1.summit ~]$ gfortran --version
GNU Fortran (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So, “cc --version” is a bit worrying.
Quite sometimes, software unconditionally calls “cc” (“c++”), expecting that it is the same as “gcc” (“g++”).
So, “cc” (“c++”) should be a symbolic link to “gcc” (“g++”).
Maybe you could try to talk to your system administrators.
Well, try (it returns “cc” for me): root-config --cc
It means that ROOT considers “gcc” to be the C compiler.
However, other software which uses ROOT libraries often defaults to “cc” (I’ve had it many times).
I would ask administrators to make a symbolic link from “gcc” to “cc” (there already exists the link from “g++” to “c++”).
When writing my own makefiles, I always use: CC=$(shell root-config --cc) CXX=$(shell root-config --cxx)
When running “./configure”, the first several lines will tell you which C, C++, and F77 compilers it will try to use.
BTW. @pcanal committed the fix. Try to get the newest source code and build it from scratch (just to make sure it works fine).
Well, I think I understand what you mean. The small “bin/root” front-end program is not present. This is normal when you request “--disable-x11” (you then get the real ROOT executables, “root.exe” and “rootn.exe”, only).
BTW. If you have the default GCC 8.3.1 suite installed, can it be that you also have some default Python? Without loading any module, try “python2 --version” and “python3 --version”.
It seems to me that a better idea would be to use one of these default Python versions.
Create a symbolic link to “python” and make sure that the corresponding “devel” package is installed, too.
Could you elaborate on why this way is better? (and why we need to install the python2-devel package?)
(or what might be problematic if we just load the python module)
If one (i.e., ROOT) wants to link against “python3” (“python2”) shared libraries, one needs the corresponding “python3-devel” (“python2-devel”) package.
I think one needs the “python” symbolic link only when building ROOT (with “./configure” but not with CMake). Afterward, one can simply explicitly call “python3” (“python2”) and “import ROOT”.
In general, I prefer the system-provided Python versions. I assume they get “bug fixes” at regular intervals, and there are usually plenty of additional packages available (the “numpy” being the most important for ROOT users).
Strangely, you have the 2.7.17 version, though you should have the 2.7.18 (lazy system administrators?).
I don’t trust “extra modules”. They are compiled by somebody at one time. From my experience, they are purely tested, and they never get “bug fixes”.
If you really want a specific version of some software, you need to build it and maintain it yourself (like you do with ROOT).
Hi this is a follow-up: are there any standard checks within ROOT to make sure ROOT (and each module like roofit etc) is built correctly and returns the same result as another ROOT build on other machines? I assume we can use the example macros in the /tutorial directory?