OK, I got it installed though with some pain. First, after some more searching, I found that the mpi4py incompatibility had previously been reported here: https://bitbucket.org/mpi4py/mpi4py/issues/112/new-release-needed . And there was a new release of mpi4py to fix it: 3.0.1. I tried to install that with pip, but pip refused to acknowledge that there was a version more recent than 3.0.0. I therefore downloaded the mpi4py-3.0.1 tarball and installed from source. That went fine. And, miracle of miracles, the pip install of dolfin also worked without any reported errors. But there was still trouble in paradise. When I tried to import fenics, I got errors about conflicts in the shared object cpp.cpython-37m-x86_64-linux-gnu.so . In particular, it was loading several libraries from /lib64. On this system, those libraries are largely nonfunctional. Instead, we need to use shared libraries found in Lua environment modules whose directories are listed in LIBRARY_PATH. The question then was why the cpp shared library insisted on looking in /lib64. So now, in order to do the build somewhere that I could get back to (pip does the build in temporary directories which it then deletes), I built by direct invocation of setup.py:
setenv PYBIND11_DIR $FENICS
python setup.py -v build
python setup.py -v install
To find out why /lib64 objects were being invoked, I edited CMakeLists.txt to contain the following line:
set(CMAKE_VERBOSE_MAKEFILE ON)
I then repeated the build and install, this time getting full output from make. The command to create the dolfin.cpp library was roughly as follows (I have shortened it):
c++ -fPIC -DVERSION_INFO=“2018.2.0.dev0” -O3 -DNDEBUG -shared -Wl,-soname,cpp.cpython-37m-x86_64-linux-gnu.so -o …/lib.linux-x86_64-3.7/dolfin/cpp.cpython-37m-x86_64-linux-gnu.so CMakeFiles/cpp.dir/src/dolfin.cpp.o <many more .o files> -L/lib64 -Wl,-rpath,/lib64 -Flto /home/lavery/projects/def-bingalls/lavery/FENICS/lib64/libdolfin.so.2018.2.0.dev0
It is the -L/lib64 -Wl,-rpath,/lib64 options that cause the trouble, of course. I thus manually executed the command with these two options deleted. That gave me a shared object that, according to ldd, references nothing in /lib64. I copied it into the appropriate places in my virtualenv. Now I can import fenics and mpi4py. What’s more:
In [2]: import fenics as fe
In [3]: fe.MPI.comm_world
Out[3]: <mpi4py.MPI.Intracomm at 0x7fdb3412ef30>
So the fenics mpi4py integration is indeed working as it ought to. At the moment, it looks like a happy ending.