Package: openmpi-bin Version: 3.1.3-1 Severity: important User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:combblas
openmpi-bin is currently marked Multi-Arch: foreign as a result of #901874. I note that none of the solutions for that that I offered involved marking a package containing mpicc Multi-Arch: foreign. The fix to that bug was an error and is now causing further problems. More specifically, cmake's FindMPI.cmake is now finding that mpicc "works" (except that it gets us wrong include directories) and since mpicc works, it skips over the working detection using pkg-config thus failing to find a working MPI implementation. If openmpi-bin were not Multi-Arch: foreign, mpicc would fail (rather than produce broken results) and cause FindMPI to successfully detect MPI using pkg-config. My last mail to that earlier bug said: | So you have a choice here: | | A. Ship <triplet>-mpicc and make everyone use AC_PATH_TOOL over | AC_PATH_PROG. | | B. Make libopenmpi-dev Multi-Arch: no and let mpicc operate for whatever | architecture it was installed for. | | C. Ignore the problem and move to pkg-config directly. I think we're effectively moving towards option C now, but there is a complication. How do we decide whether try mpicc or pkg-config first? If we try mpicc first, we end up risking to use the broken version of openmpi-bin that doesn't work but looks like it works. So we either need to convince everyone to try pkg-config before mpicc (which cmake's FindMPI doesn't do at present) or we need to ensure that mpicc fails reliably when it does not work. I'm effectively asking for the latter here. Helmut
