Install Root v5.34.34

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:

./configure --disable-unuran --disable-vc --enable-soversion --enable-minuit2 --enable-roofit --enable-python --disable-x11 --disable-mysql --build=debug
make

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).

this is the output

[wshi@login4.summit v5-34-00-patches]$ echo $ROOTSYS
/ccs/home/wshi/SeparateTrial/v5-34-00-patches
[wshi@login4.summit v5-34-00-patches]$ : | gcc -dM -E -x c - | grep -i endian
#define __ORDER_LITTLE_ENDIAN__ 1234
#define _LITTLE_ENDIAN 1
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __VEC_ELEMENT_REG_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__

I find there are pre-installed python on the machine, so I can simply load one of them.

[wshi@login4.summit v5-34-00-patches]$ python --version
-bash: python: command not found
[wshi@login4.summit v5-34-00-patches]$ module available python

------------------------------------------------------- /sw/summit/spack-envs/base/modules/spack/linux-rhel8-ppc64le/Core --------------------------------------------------------
   python/2.7.15    python/3.7.7    python/3.8.10

------------------------------------------------------------------ /sw/summit/spack-envs/base/modules/site/Core ------------------------------------------------------------------
   python/3.6-anaconda3    python/3.6.10-anaconda3    python/3.7-anaconda3    python/3.8-anaconda3 (D)

-------------------------------------------------------------------------- /sw/summit/modulefiles/core ---------------------------------------------------------------------------
   python/2.7.15-anaconda2-5.3.0

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 ...”).

I am loading python2 (all three versions are built with gcc-8.3.1, ROOT5 is built with gcc-7.5.0, would these two gcc versions conflict?)

[wshi@login5.summit ProdROOT]$ module load python/2.7.15
[wshi@login5.summit ProdROOT]$ which python
/sw/summit/spack-envs/base/opt/linux-rhel8-ppc64le/gcc-8.3.1/python-2.7.15-6u3drknv3x3ocyhzgcqzrxjdaccpuxcp/bin/python

and configure with the following

./configure --disable-unuran --disable-vc --enable-soversion --enable-minuit2 --enable-roofit --enable-python --disable-x11 --disable-mysql

Which compiler option should I add then: --enable-cxx17, or --enable-cxx20?

Btw, is the following considered a final fix? Is this going to be committed to the root v5 patches branch?

You’d better never mix compilers.
Compile your ROOT with gcc 8.3.1 (I don’t expect problems) if your β€œpython” uses it.

You may need the additional β€œ--enable-cxx11” or β€œ--enable-cxx14” flag with compilers that default to C++17 (in my case gcc 11.x).

I’ve already asked @pcanal to implement a fix in the form (actually, you could test it):

#   if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#      define R__BYTESWAP
#   endif

The machine doesn’t provide gcc 8.3.1 for users to load though.

[wshi@login5.summit ~]$ module available gcc

------------------------------------------------------------------ /sw/summit/spack-envs/base/modules/site/Core ------------------------------------------------------------------
   gcc/7.5.0 (L)    gcc/9.1.0 (D)    gcc/9.3.0    gcc/10.2.0    gcc/11.1.0    gcc/11.2.0    gcc/12.1.0

-------------------------------------------------------------------------- /sw/summit/modulefiles/core ---------------------------------------------------------------------------
   hdf5_perf/1.10.6.gcc

  Where:
   L:  Module is loaded
   D:  Default Module

What’s the best way to proceed?

That is strange.
How come they provide software built with compilers that they do not provide?

Can it be that gcc 8.3 is the default compiler on this system (and you do not need to load any additional module)?

If not, from your list, gcc 9.1.0 is marked as the β€œD: Default Module” so maybe you could try to build ROOT with it.

You are right, 8.3.1 is the default, I don’t need to load.

o.k. make sure you have β€œgcc”, β€œcc”, β€œg++”, β€œc++”, and β€œgfortran” available (check all of them with β€œ--version”).

Here they are:

[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

Using my previous ROOT built without enabling python/roofit/minuit, it gives:

[wshi@login5.summit v5-34-00-patches]$ root-config --cc

gcc

Then this means ROOT expects cc to be the same as gcc? and I should ask admin to sym link the two?

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).

The output of configure (with gcc8.3.1 and python/2.7.15)

./configure --disable-unuran --disable-vc --enable-soversion --enable-minuit2 --enable-roofit --enable-python --disable-x11 --disable-mysql

is attached.
configure.out.txt (6.3 KB)

Under which gcc should I test, 8.3.1?

The newest source code should work with any compiler.

BTW. Your new β€œconfigure” output looks fine.

Build is successful with gcc 7.5.0 using this

./configure --disable-unuran --disable-vc --enable-soversion --build=debug
make

Build with gcc 8.3.1 says successful, but the β€œbin/root ” executable is not built. make output attached

./configure --disable-unuran --disable-vc --enable-soversion --enable-minuit2 --enable-roofit --enable-python --disable-x11 --disable-mysql
make

make.out.txt (2.9 MB)

I can see it:

(...)
bin/rmkdepend -R -fmain/src/rmain.d -Y -w 1000 -- -pipe -Wall -m64 -fPIC -fsigned-char -DR__ppc64 -I/usr/X11/include -Iinclude    -pthread -D__cplusplus -- /autofs/nccs-svm1_home1/wshi/ProdROOT/v5-34-00-patches/main/src/rmain.cxx
g++ -O2 -pipe -Wall -m64 -fPIC -fsigned-char -DR__ppc64 -I/usr/X11/include -Iinclude    -pthread -o main/src/rmain.o -c /autofs/nccs-svm1_home1/wshi/ProdROOT/v5-34-00-patches/main/src/rmain.cxx
g++ -m64 -O2  -o bin/root.exe main/src/rmain.o  \
	   -Llib -lCore -lCint -lRint -lm -ldl  -pthread  
g++ -m64 -O2  -o bin/rootn.exe main/src/rmain.o  \
	   -Llib -lNew -lCore -lCint -lRint -lm -ldl  -pthread  
(...)

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 does have default python:

[wshi@login2.summit ~]$ python2 --version
Python 2.7.17
[wshi@login2.summit ~]$ python3 --version
Python 3.6.8

Also ROOT5 builds fine with gcc 8.3.1 and python/2.7.15, I think it is working now. Thanks all very much for helping me!

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.