Install Root v5.34.34

ROOT
77

Looking at this output, it seems that at “$42” the “rs” has a proper value in “fLong” (“fShort” is empty), but then, several lines below, inside of “gSystem->DirName(rs)”, at “233” the “TString::GetShortPointer” is called. It seems that the “TString::IsLong” at "216 misbehaved.

@Axel / @pcanal Can it be that the problem originates in “R__BYTESWAP”? Is something missing in “core/base/inc/RConfig.h” for the “linuxppc64gcc” target?

@weishi A desperate trial …start from scratch again (in a different directory so that you do not destroy your current setup), and before running “./configure”, modify “core/base/inc/RConfig.h” adding one line inside (before the line 327 with “R__ppc64”):

#   define R__BYTESWAP
#   if defined(R__ppc64)
1 Like
78

Probably unrelated, but clang static analyzer finds some issues with the TString::IsLong function, see:

79

@ferhue We are dealing here with the “v5-34-00-patches” branch.

80

I know, but the same bug might affect 5.34

81

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

82

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

83

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
84

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

85

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?

86

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
87

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?

88

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.

89

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

90

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

91

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

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

93

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?

94

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

95

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?

96

The newest source code should work with any compiler.

BTW. Your new “configure” output looks fine.