Install Root v5.34.34

Wile_E_Coyote · October 31, 2022, 7:20pm

There is something wrong. At least the second “find” should return some six unrelated “iosenum/iosenum.solaris*” files.

Another trial:
find ${ROOTSYS}/cint -name "*.so*" -print
find ${ROOTSYS} -name iosenum.solaris -print

weishi · October 31, 2022, 7:29pm

I am not getting any output still. Just to clarify, I am assuming we are now talking about cmake build and try to find these dll files.

We are not talking under the configure/make scenario: ./configure --disable-unuran --disable-vc --enable-soversion --build=debug

ferhue · October 31, 2022, 7:31pm

I think Wile means the “configure” scenario.

Wile_E_Coyote · October 31, 2022, 7:34pm

I assumed you were using “./configure”.

When using CMake, in your “build” directory, check:

./lib/climits.dll
./lib/posix.dll
./lib/queue.dll
./lib/stack.dll
./lib/stdcxxfunc.dll
./lib/map2.dll
./lib/exception.dll
./lib/multimap.dll
./lib/valarray.dll
./lib/stdfunc.dll
./lib/set.dll
./lib/deque.dll
./lib/multiset.dll
./lib/list.dll
./lib/ipc.dll
./lib/vector.dll
./lib/stdexcept.dll
./lib/map.dll
./lib/complex.dll
./lib/multimap2.dll
./lib/vectorbool.dll

However, in any case, in the end, you should have:

./cint/cint/include/posix.dll
./cint/cint/include/stdcxxfunc.dll
./cint/cint/include/stdfunc.dll
./cint/cint/include/ipc.dll
./cint/cint/stl/climits.dll
./cint/cint/stl/queue.dll
./cint/cint/stl/stack.dll
./cint/cint/stl/map2.dll
./cint/cint/stl/exception.dll
./cint/cint/stl/multimap.dll
./cint/cint/stl/valarray.dll
./cint/cint/stl/set.dll
./cint/cint/stl/deque.dll
./cint/cint/stl/multiset.dll
./cint/cint/stl/list.dll
./cint/cint/stl/vector.dll
./cint/cint/stl/stdexcept.dll
./cint/cint/stl/map.dll
./cint/cint/stl/complex.dll
./cint/cint/stl/multimap2.dll
./cint/cint/stl/vectorbool.dll

weishi · October 31, 2022, 9:12pm

Using ./configure, I have all 21 dlls

[wshi@login5.summit include]$ pwd
/ccs/home/wshi/ROOT/v5-34-00-patches/cint/cint/include
[wshi@login5.summit include]$ ls -la *.dll
lrwxrwxrwx 1 wshi wshi  8 Oct 31 16:44 ipc.dll -> ipc.so.5
lrwxrwxrwx 1 wshi wshi 10 Oct 31 16:44 posix.dll -> posix.so.5
lrwxrwxrwx 1 wshi wshi 15 Oct 31 16:44 stdcxxfunc.dll -> stdcxxfunc.so.5
lrwxrwxrwx 1 wshi wshi 12 Oct 31 16:44 stdfunc.dll -> stdfunc.so.5

[wshi@login5.summit stl]$ pwd
/ccs/home/wshi/ROOT/v5-34-00-patches/cint/cint/stl
[wshi@login5.summit stl]$ ls -la *.dll
lrwxrwxrwx 1 wshi wshi 12 Oct 31 16:43 climits.dll -> climits.so.5
lrwxrwxrwx 1 wshi wshi 12 Oct 31 16:44 complex.dll -> complex.so.5
lrwxrwxrwx 1 wshi wshi 10 Oct 31 16:42 deque.dll -> deque.so.5
lrwxrwxrwx 1 wshi wshi 14 Oct 31 16:43 exception.dll -> exception.so.5
lrwxrwxrwx 1 wshi wshi  9 Oct 31 16:42 list.dll -> list.so.5
lrwxrwxrwx 1 wshi wshi  8 Oct 31 16:43 map.dll -> map.so.5
lrwxrwxrwx 1 wshi wshi  9 Oct 31 16:43 map2.dll -> map2.so.5
lrwxrwxrwx 1 wshi wshi 13 Oct 31 16:43 multimap.dll -> multimap.so.5
lrwxrwxrwx 1 wshi wshi 14 Oct 31 16:43 multimap2.dll -> multimap2.so.5
lrwxrwxrwx 1 wshi wshi 13 Oct 31 16:43 multiset.dll -> multiset.so.5
lrwxrwxrwx 1 wshi wshi 10 Oct 31 16:43 queue.dll -> queue.so.5
lrwxrwxrwx 1 wshi wshi  8 Oct 31 16:43 set.dll -> set.so.5
lrwxrwxrwx 1 wshi wshi 10 Oct 31 16:43 stack.dll -> stack.so.5
lrwxrwxrwx 1 wshi wshi 14 Oct 31 16:43 stdexcept.dll -> stdexcept.so.5
lrwxrwxrwx 1 wshi wshi 13 Oct 31 16:44 valarray.dll -> valarray.so.5
lrwxrwxrwx 1 wshi wshi 11 Oct 31 16:42 vector.dll -> vector.so.5
lrwxrwxrwx 1 wshi wshi 15 Oct 31 16:42 vectorbool.dll -> vectorbool.so.5

What does this indicate then?

weishi · November 1, 2022, 11:15pm

Is there any more suggestions on this?

Axel · November 2, 2022, 12:21am

Let’s step back for a second:

If I understand correctly you are trying to build ROOT but the binary called root is missing? Which version of ROOT, which compiler? Can you share the configuration invocation and output, please?

Disclaimer: we do not support XLClang - we don’t even support 5.34 anymore, and it’s no surprise to me that a > 10 years old version of ROOT doesn’t build on today’s operating systems, despite Wile_E’s heroic efforts in keeping a minimal lifeline

weishi · November 2, 2022, 2:44am

Hi, as a summary, we need to build ROOT5 for an analysis framework, which can’t move to ROOT6 in immediate future. We are installing ROOT5 on the OakRidge Summit cluster (IBM power9 processor).

I can use the following configure/make to build ROOT5 v5-34-00-patches fine:

git clone -b v5-34-00-patches http://root.cern.ch/git/root.git v5-34-00-patches
module load gcc/7.5.0
./configure --disable-unuran --disable-vc --enable-soversion --build=debug
make

But when opening root -l, we saw the error “no file name specified” described here (here root binary is NOT built): Install Root v5.34.34 - #9 by weishi

Then Wile suggested the extra option to configure --disable-unuran --disable-vc, and I can see root binary is built, yet it still shows similar error as described here: Install Root v5.34.34 - #21 by weishi

The cluster have many gcc installed, a list of them here:
Compiler: gcc/7.5.0 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

Here are more details of the machine

NAME="Red Hat Enterprise Linux"
VERSION="8.2 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.2"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.2 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8.2:GA"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.2
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.2"

We also tried cmake build, but with limited progress as said here: Install Root v5.34.34 - #31 by weishi

Wei

Wile_E_Coyote · November 2, 2022, 8:12am

There’s something that came to my mind.
While playing with it, you often “source /.../thisroot. sh”. It modifies various environment variables (e.g., “ROOTSYS”, “PATH”, “LD_LIBRARY_PATH” and “PYTHONPATH”).
Before configuring and making your new ROOT, make sure that nothing in your environment points to another ROOT version and “unset ROOTSYS”. So, always start from a new terminal window with a new shell.

Axel · November 2, 2022, 9:25am

Thank you. There is very likely a build error that we didn’t see; could you check the exit code of make?

Any make error (such as make: g77: Command not found) likely means that the build is incomplete. make must finish with exit code 0, or else the build is incomplete.

Wile_E_Coyote · November 2, 2022, 9:40am

@weishi Well, to make sure it builds “as much as possible”, use: make -k ; make -k

@Axel One of the last lines of the “make.out.txt” says (yes, it may miss some Fortran related utilities):

   ===                ROOT BUILD SUCCESSFUL.                ===

Probably the loaded cluster module that provides gcc/g++ does not provide gfortran as the “configure.out.txt” says:

Checking for F77 compiler ... no F77 compiler g77 found

@weishi If there is the “gfortran”, then “./configure” misbehaves.

Axel · November 2, 2022, 9:55am

Please don’t use make -k when we don’t know what’s going wrong with a build - it will hide the failure…

I would like to reduce the number of “and I also tried this” to exactly 0: can we focus on one approach, one configuration line, and one problem, to avoid me from losing track of what we are talking about? We should try with GCC 7.5.

Wile_E_Coyote · November 2, 2022, 10:03am

The second “make -k” will immediately dump all fatal problems.

weishi · November 2, 2022, 3:18pm

With the configure/make way I said above, the second make -k shows:

[wshi@login4.summit v5-34-00-patches]$ make -k
make: g77: Command not found
make: g77: Command not found
 
   ============================================================
   ===                ROOT BUILD SUCCESSFUL.                ===
   === Run 'source bin/thisroot.[c]sh' before starting ROOT ===
   ============================================================

There also is gfortran

[wshi@login4.summit v5-34-00-patches]$ which gfortran
/sw/summit/gcc/7.5.0-2/bin/gfortran

Wile_E_Coyote · November 2, 2022, 3:31pm

O.K. So the problem is in the “config/Makefile.linuxppc64gcc” file which knows “g77” only (see, e.g., “config/Makefile.linuxx8664gcc”).

weishi · November 2, 2022, 5:11pm

I attached the configure&make output, fyi @Axel
configure.out.txt (6.8 KB)
make.out.txt (2.1 MB)

@Wile_E_Coyote
I attached the two make file configs,
ppc: https://raw.githubusercontent.com/weishi10141993/NeutrinoPhysics/main/MaCh3/Makefile.linuxppc64gcc
x8664: https://raw.githubusercontent.com/weishi10141993/NeutrinoPhysics/main/MaCh3/Makefile.linuxx8664gcc

I changed the section “# Fortran:” in ppc64 make file to match those in x8664 make file, and indeed the make: g77: Command not found error is gone, but opening root shows similar error as before

[wshi@login5.summit v5-34-00-patches]$ root -l
Error in <UnknownClass::ReadFile>: no file name specified
Error in <UnknownClass::ReadFile>: no file name specified
Error in <TEnv::ReadFile>: no file name specified
Error in <TEnv::ReadFile>: no file name specified
Error in <TUnixSystem::DynamicPathName>: libMathCore[.so | .dll | .dylib | .sl | .dl | .a] does not exist in /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/lib:/ccs/home/wshi/ROOT/v5-34-00-patches/lib:/sw/summit/spack-envs/base/opt/linux-rhel8-ppc64le/gcc-7.5.0/spectrum-mpi-10.4.0.3-20210112-puowkoejepfjtm22sk2dxb6eeup5w447/lib:/sw/summit/gcc/7.5.0-2/lib64:/sw/summit/spack-envs/base/opt/linux-rhel8-ppc64le/gcc-8.3.1/darshan-runtime-3.3.0-mu6tnxlhxfplrq3srkkgi5dvly6wenwy/lib:/opt/ibm/spectrumcomputing/lsf/10.1.0.11/linux3.10-glibc2.17-ppc64le-csm/lib:.:./lib:
aborting
#0  0x00007fff94b29c34 in waitpid () from /lib64/power9/libc.so.6
#1  0x00007fff94a94340 in do_system () from /lib64/power9/libc.so.6
#2  0x00007fff94c68ec8 in system_compat () from /lib64/power9/libpthread.so.0
#3  0x00007fff95ed17f0 in TUnixSystem::Exec (this=0x3d05c650, shellcmd=0x3d203a30 "./etc/gdb-backtrace.sh 3574836 1>&2") at /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/core/unix/src/TUnixSystem.cxx:2172
#4  0x00007fff95ed23c8 in TUnixSystem::StackTrace (this=0x3d05c650) at /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/core/unix/src/TUnixSystem.cxx:2419
#5  0x00007fff95dc1eac in DefaultErrorHandler (level=773880864, abort_bool=100, location=0x206c732e207c2062 <error: Cannot access memory at address 0x206c732e207c2062>, msg=0x207c206c642e207c <error: Cannot access memory at address 0x207c206c642e207c>) at /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/core/base/src/TError.cxx:192
#6  0x73772f31656d6f68 in ?? ()

Wile_E_Coyote · November 3, 2022, 9:43am

Well, can you try to “test” the dynamic linker (ignore several possible “not a dynamic executable” messages):
ldd ${ROOTSYS}/lib/*.so | grep "found" | sort -u

weishi · November 3, 2022, 2:57pm

here is the output (this is done after changed the section “# Fortran:” in ppc64 make file to match those in x8664 make file)

[wshi@login5.summit v5-34-00-patches]$ ldd ${ROOTSYS}/lib/*.so | grep "found" | sort -u
	libgfortran.so.4 => not found

FYI, I am also attaching the output of ldd ${ROOTSYS}/lib/*.so | sort -u:
ldd_out.txt (115.1 KB)

Wile_E_Coyote · November 3, 2022, 4:27pm

That’s a bit strange.
Do you follow this procedure … in a new terminal window (in a new shell), first “load the gcc 7.5 cluster module”, then “source thisroot.sh”, and finally try “ldd” (or run “root”).

BTW. @pcanal committed “config/Makefile.linuxppc64gcc” changes so you could try to download the newest “v5-34-00-patches” version and build it from scratch again (just to make sure that it builds fine).

weishi · November 3, 2022, 5:57pm

So I git cloned the newest branch and it builds fine, here is what I did to be exact:

module load gcc/7.5.0
git clone -b v5-34-00-patches http://root.cern.ch/git/root.git v5-34-00-patches (latest)
./configure --disable-unuran --disable-vc --enable-soversion --build=debug > configure.out.txt 2>&1
make > make.out.txt 2>&1
source bin/thisroot.sh

the output logs are here
configure.out.txt (6.8 KB)
make.out.txt (2.1 MB)

Then ldd returns nothing:

[wshi@login1.summit v5-34-00-patches]$ ldd ${ROOTSYS}/lib/*.so | grep "found" | sort -u
[wshi@login1.summit v5-34-00-patches]$ echo $ROOTSYS
/ccs/home/wshi/ROOT/v5-34-00-patches
[wshi@login1.summit v5-34-00-patches]$ root -l
Error in <UnknownClass::ReadFile>: no file name specified
Error in <UnknownClass::ReadFile>: no file name specified
Error in <TEnv::ReadFile>: no file name specified
Error in <TEnv::ReadFile>: no file name specified
Error in <TUnixSystem::DynamicPathName>: libMathCore[.so | .dll | .dylib | .sl | .dl | .a] does not exist in /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/lib:/ccs/home/wshi/ROOT/v5-34-00-patches/lib:/sw/summit/spack-envs/base/opt/linux-rhel8-ppc64le/gcc-7.5.0/spectrum-mpi-10.4.0.3-20210112-puowkoejepfjtm22sk2dxb6eeup5w447/lib:/sw/summit/gcc/7.5.0-2/lib64:/sw/summit/spack-envs/base/opt/linux-rhel8-ppc64le/gcc-8.3.1/darshan-runtime-3.3.0-mu6tnxlhxfplrq3srkkgi5dvly6wenwy/lib:/opt/ibm/spectrumcomputing/lsf/10.1.0.11/linux3.10-glibc2.17-ppc64le-csm/lib:.:./lib:
aborting
#0  0x00007fff8a679c34 in waitpid () from /lib64/power9/libc.so.6
#1  0x00007fff8a5e4340 in do_system () from /lib64/power9/libc.so.6
#2  0x00007fff8a7b8ec8 in system_compat () from /lib64/power9/libpthread.so.0
#3  0x00007fff8ba217f0 in TUnixSystem::Exec (this=0x3a4ac6b0, shellcmd=0x3a652ff0 "./etc/gdb-backtrace.sh 253775 1>&2") at /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/core/unix/src/TUnixSystem.cxx:2172
#4  0x00007fff8ba223c8 in TUnixSystem::StackTrace (this=0x3a4ac6b0) at /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/core/unix/src/TUnixSystem.cxx:2419
#5  0x00007fff8b911eac in DefaultErrorHandler (level=773880864, abort_bool=100, location=0x206c732e207c2062 <error: Cannot access memory at address 0x206c732e207c2062>, msg=0x207c206c642e207c <error: Cannot access memory at address 0x207c206c642e207c>) at /autofs/nccs-svm1_home1/wshi/ROOT/v5-34-00-patches/core/base/src/TError.cxx:192
#6  0x73772f31656d6f68 in ?? ()

Full output of ldd ${ROOTSYS}/lib/*.so here:
ldd_log.txt (118.5 KB)