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
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-
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).
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).
I’m not sure how you got as far as you did with your configuration . 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?
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?
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
. A simple “just paraview” with Intel worked. Trying to do 