I’m trying to build ParaView 5.8 on Argonne’s Theta supercomputer using gcc 9.3.0. ParaView’s dependencies are installed via spack, but I’m building ParaView manually using cmake. After 16%, I’m getting the following error:
I suspect that the login node is cross-compiling for the compute nodes, and the ParaView build process builds a program that it then run on the login node as part of the build process (cpp protocol buffer compiler), leading to the Illegal instruction message.
This seems to be confirmed by the fact that if I get a job allocation and continue running make on a compute node, this step is able to continue (however I’m running into other problems later that I’m trying to solve).
I was wondering if you ever ran into such cross-compilation problems, and if you have a fix for it?
Previous installs we’ve done there used ParaView Superbuild, because spack was in early stages. We should move to spack though. If my memory serves, @Scott_Wittenburg did a 5.8 there via Superbuild.
I don’t have any suggestions yet on that particular compile problem unfortunately.
The paraview superbuild is still configured by cmake, it just builds all the dependencies as well as paraview. So the variables you give it are superbuild specific, if you try to set variables you’re used to setting when building paraview alone, it won’t recognize them. Note however, there is a way to pass variables to the paraview build by building a string of cli-style “-D” arguments, ala [1].
For an example of how it can be run, look at this file [2] in the change I linked above. That script controls the build process, while the cmake file [3] contains the configuration settings of the build.
I’ll just note also that the superbuild process is often a bit harrowing, and typically requires combing through a haystack of log messages looking for the needle of what went wrong. So I’m really looking forward to when we can rely on spack to build paraview and its dependencies. We’re making progress in that direction, but it has its own challenges, as you’ve seen.
Thanks, I ended up managing to build using cmake by starting the build until it fails, then getting an allocation on a compute node, running make again there just to get the failing target to build, then killing the make process and going back to the login node to restart it. I had to make sure that the same modules were loaded on the login node and on the compute node but after a few tries I managed.
I recall trying with spack at some point and it was failing with the same kind of problem, so I think spack isn’t necessarily the answer. The solution is probably to figure out how to have cmake build the cpp protocol buffer compiler for the login node rather than for the compute node. I have no idea how cmake can handle this, though.