This desperate trial works! (with ./configure --disable-unuran --disable-vc --enable-soversion --build=debug & make) I can open root and browse root files.
For our analysis though, we need to add a few more options (--enable-minuit2 --enable-roofit --enable-python --disable-x11 --disable-mysql). With this:
I canβt see the root binary built unfortunately. Does any of the extra option conflict with --disable-unuran --disable-vc?
PS. With these options root binary can be built: ./configure --disable-unuran --disable-vc --enable-soversion --build=debug --enable-minuit2 --enable-roofit
Can you post the output of: : | gcc -dM -E -x c - | grep -i endian
If you want the β--enable-pythonβ feature, you need to have the βpythonβ executable and its corresponding βpython-develβ package installed.
If βpython --versionβ says you have no βpythonβ executable, try. e.g.: ln -sf /usr/bin/python2 ${HOME}/bin/python
You may then also need to install the βpython2-develβ package, of course,
Note: I do not know how good or bad the support for a modern βpython3β is.
BTW. Use β--build=debugβ only for debugging purposes (your βproductionβ version should be built without it). Also, I think, β--disable-x11 --disable-mysqlβ should not generate any problems (in this case, attach both β*.out.txtβ files for inspection).
You can try to build and test ROOT with the first three (forget β*anaconda*β) in separate directories.
Note: you may need to use the same compiler version that was used to build these βpythonβ distributions (with new C++17 compilers, use β./configure --enable-cxx11 ...β or β./configure --enable-cxx14 ...β).
[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.