Just for the record: in mpgrafic-0.3.9-1, the symptoms of this bug remain - mpgrafic-0.3.9-1 fails to build on s390x, ppc64, ppc64, sparc64:
https://buildd.debian.org/status/fetch.php?pkg=mpgrafic&arch=s390x&ver=0.3.9-1&stamp=1485163445&raw=0 FAIL: regression-test-0.3.7.9.sh ================================ Code regression test: does the standard input file generate an output file identical to that produced by version 0.3.7.9 of mpgrafic? IEEE_UNDERFLOW_FLAG and IEEE_DENORMAL exceptions are considered acceptable and ignored. Other minor warnings are ignored too on some systems/implementations. This looks like a debian openmpi system. [zemlinsky:3690] *** An error occurred in MPI_Comm_dup [zemlinsky:3690] *** reported by process [1324089345,0] [zemlinsky:3690] *** on communicator MPI_COMM_WORLD [zemlinsky:3690] *** MPI_ERR_COMM: invalid communicator [zemlinsky:3690] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [zemlinsky:3690] *** and potentially your MPI job) Warning: A 32^3 mpi run of mpgrafic did not match the expected output. Equivalent output is on: https://buildd.debian.org/status/fetch.php?pkg=mpgrafic&arch=ppc64&ver=0.3.9-1&stamp=1485164619&raw=0 https://buildd.debian.org/status/fetch.php?pkg=mpgrafic&arch=sparc64&ver=0.3.9-1&stamp=1485164111&raw=0 with the process lines: [ookuninushi:8387] *** reported by process [1226178561,0] [landau:151008] *** reported by process [2975596545,0] Possible clue: Does the line "*** reported by process [1324089345,0]" mean that the PID number is assumed to be 1324089345? It sounds extremely high for a PID. Unsigned 32-bit integers go up to approx 4e9. A build of mpgrafic should not spawn a billion or so processes :P. This looks like a report from lines 25-29 of ompi/errhandler/help-mpi-errors.txt 25 [mpi_errors_are_fatal] 26 %s *** An error occurred %s %s 27 %s *** reported by process [%lu,%lu] 28 %s *** on %s %s 29 %s *** %s Another possible clue: line 988 of ompi/communicator/comm.c 988 rc = ompi_comm_set ( &newcomp, /* new comm */ uses a pointer to a pointer for the new communicator. So a bug related to fortran-C interfacing (non-use of iso_C_binding?) together with endianness for a pointer to a pointer might be the source of the bug.
