Superbuild 'install' target fails with v5.10

Hello,

I have just been trying to install a CATALYST_RENDERING superbuild of ParaView v5.10.0 on a Linux HPC cluster that seems to build fine (and works fine for me from the build directory) but I can’t seem to install it.

When I run ninja install, it fails with following error output:

CMake Error at cmake_install.cmake:57 (message):
  Failed to install
  /home/mr618/rds/rds-dirac-dp128/mr618/paraview/build-v5.10/install/bin/pvdataserver:


  /sbin/ldconfig: Can't stat /libx32: No such file or directory

  /sbin/ldconfig: Path `/usr/lib' given more than once

  (from <builtin>:0 and <builtin>:0)

  /sbin/ldconfig: Path `/usr/lib64' given more than once

  (from <builtin>:0 and <builtin>:0)

  /sbin/ldconfig: Can't stat /usr/libx32: No such file or directory

  RUNPATH string offset not contained in string tableTraceback (most recent
  call last):

    File "/home/mr618/rds/rds-dirac-dp128/mr618/paraview/paraview-superbuild-v5.10/superbuild/cmake/scripts/fixup_bundle.unix.py", line 750, in <module>
      main(sys.argv[1:])
    File "/home/mr618/rds/rds-dirac-dp128/mr618/paraview/paraview-superbuild-v5.10/superbuild/cmake/scripts/fixup_bundle.unix.py", line 742, in main
      _install_binary(main_exe, is_excluded, bundle_dest, opts.libdir, installed, manifest, opts.source, dry_run=opts.dry_run, look_for_symlinks=opts.has_symlinks)
    File "/home/mr618/rds/rds-dirac-dp128/mr618/paraview/paraview-superbuild-v5.10/superbuild/cmake/scripts/fixup_bundle.unix.py", line 628, in _install_binary
      installed[dep.path] = (dep, copy_library(bundle_dest, dep_libdir, dep, sources, dry_run=dry_run))
    File "/home/mr618/rds/rds-dirac-dp128/mr618/paraview/paraview-superbuild-v5.10/superbuild/cmake/scripts/fixup_bundle.unix.py", line 463, in copy_library
      remove_prefix_rpaths(binary, libdir, sources)
    File "/home/mr618/rds/rds-dirac-dp128/mr618/paraview/paraview-superbuild-v5.10/superbuild/cmake/scripts/fixup_bundle.unix.py", line 504, in remove_prefix_rpaths
      old_path = chrpath().strip().split('=')[1]
    File "/home/mr618/rds/rds-dirac-dp128/mr618/paraview/paraview-superbuild-v5.10/superbuild/cmake/scripts/fixup_bundle.unix.py", line 39, in __call__
      raise RuntimeError('failed to execute pipeline:\n%s' % stderr)

  RuntimeError: failed to execute pipeline:

  None



gmake: *** [Makefile:115: install] Error 1
CMake Error at superbuild/cmake_install.cmake:66 (message):
  Failed to install the paraview/TGZ package.
Call Stack (most recent call first):
  cmake_install.cmake:47 (include)


FAILED: CMakeFiles/install.util
cd /home/mr618/rds/rds-dirac-dp128/mr618/paraview/build-v5.10 && /usr/bin/cmake -P cmake_install.cmake
ninja: build stopped: subcommand failed.

In case it’s helpful, please find my CMakeCache.txt file here: CMakeCache.txt (51.9 KB)

Is this because I don’t have superuser permissions or is something else the problem? Any assistance would be appreciated :slightly_smiling_face:

AFAIK, superbuild do not use install target.

@ben.boeckel @utkarsh.ayachit

Are you sure? It’s explicitly mentioned in the readme.

Maybe this was changed. I’ll let @ben.boeckel answer.

The install target just runs one of the packages and puts it in the right place (more or less). Can you make the package on this build? ctest -R cpack-

This fails with the same error. Here’s the log:
LastTest.log (3.0 MB)

The TXZ seemed to pass. I don’t know why it would pass and TGZ would fail. It smells, to me, like something is wrong in pvdataserver itself. Searching for the error message comes up with this NixOS/patchelf issue. In the meantime, you can either:

  • extract the TXZ where you need; or
  • set TXZ as the default package through CPACK_DEFAULT_INSTALL (it has items pre-selected, so ccmake and cmake-gui should be able to help here).

Hmm, I can’t seem to find any archives for the paraview package and instead can just see some for the paraviewsdk package (both TXZ and TGZ).

Oh, this is for paraviewsdk? I missed that. Something else is probably up, but I’d have to dig in.

Well I was interested in “installing” just paraview but the only successful package at the moment seems to be paraviewsdk as far as I can see.

Ok, I took a closer look at the cmake cache and now notice that it is the Intel compiler. We may need to pass different flags to fix the runpath there. Does it work with gcc? I’ll see if I can get a build going with Intel 2021.4 in the meantime.

I will note that there is a problem with newer Intel compilers in that they “optimize” things like isnan to just always return false because -O1 and higher all apply that flag. Passing -fp-model=precise in C, C++, and Fortran flags at the superbuild level should help with anything related to that once you do have a package (it will basically want to rebuild everything from scratch too).

Let me try a GCC build and get back to you.

I’m not sure how you got as far as you did with your configuration :slight_smile: . A simple “just paraview” with Intel worked. Trying to do osmesa trips on it thinking it is some kind of GCC, and embree just outright rejects IntelLLVM as a supported compiler (likely out of ignorance).

Since it is a spack-aware build environment, I wonder if the (likely) long runpaths are getting in the way somehow. What does readelf -d install/bin/pvdataserver show?

Trying to do osmesa trips on it thinking it is some kind of GCC,

I think it might be using the system GCC to build osmesa.

embree just outright rejects IntelLLVM as a supported compiler (likely out of ignorance).

I’m actually still using the Intel classic compiler rather than the newer LLVM-based one.

What does readelf -d install/bin/pvdataserver show?

For the original build with the Intel compiler, I get this:

Dynamic section at offset 0x2c38 contains 53 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkRemotingApplication-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkUtilitiesPythonInitializer-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkRemotingServerManager-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkprotobuf-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkRemotingCore-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkPythonInterpreter-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkRemotingClientServerStream-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkPVVTKExtensionsCore-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkjsoncpp-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkIOXML-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkIOXMLParser-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkParallelCore-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkfmt-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkCommonExecutionModel-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpython3.8.so.1.0]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkCommonDataModel-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkCommonMisc-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkCommonTransforms-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkCommonMath-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkkissfft-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libvtkCommonCore-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libtbb.so.12]
 0x0000000000000001 (NEEDED)             Shared library: [libvtksys-pv5.10.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib:/usr/local/software/spack/spack-rhel8-20210927/opt/spack/linux-centos8-icelake/intel-2021.4.0/intel-oneapi-tbb-2021.4.0-3wr4mg635nfdlwaagbztar2tigmgjtri/tbb/2021.4.0/lib/intel64/gcc4.8:/home/mr618/rds/rds-dirac-dp128/mr618/paraview/build-v5.10/install/lib]
 0x000000000000000c (INIT)               0x4014a8
 0x000000000000000d (FINI)               0x401aa8
 0x0000000000000019 (INIT_ARRAY)         0x602c20
 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x602c30
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x400298
 0x0000000000000005 (STRTAB)             0x400690
 0x0000000000000006 (SYMTAB)             0x4002d0
 0x000000000000000a (STRSZ)              2533 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x603000
 0x0000000000000002 (PLTRELSZ)           672 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x401208
 0x0000000000000007 (RELA)               0x401148
 0x0000000000000008 (RELASZ)             192 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x4010c8
 0x000000006fffffff (VERNEEDNUM)         3
 0x000000006ffffff0 (VERSYM)             0x401076
 0x0000000000000000 (NULL)               0x0

I also just tried a GCC build (here’s the CMakeCache.txt (49.1 KB)) and I get pretty much exactly the same error.

Then where does this detection come from?

I haven’t seen this before and it smells like the binary is somehow bad. Can you run pvdataserver from the ParaView buildtree or the superbuild’s install/bin directory at all?

In case someone else has seen this before: @danlipsa @chuckatkins

I’m confused. What detection are you talking about? I think CMake correctly detects that it’s the classic Intel compiler.

You’re right. This binary aborts relatively quickly after executing if I don’t modify the software environment from the environment modules I have loaded (I’m on an HPC cluster). However, it seems to work fine if I unset the I_MPI_PMI_LIBRARY variable. Unfortunately this doesn’t seem to fix the packaging of paraview-TGZ.

I just tried another build (on the same system) that used slightly older versions of the Intel classic compiler (19.1.2.254) and MPI library (2019.9) and this seems to have built ok. No idea what the problem was with the first build I tried but given the GCC one failed too with the same Intel MPI library (2021.4) I’m wondering if that MPI library was the problem :thinking: