Mumps build-time tests are failing on hppa
(32-bit, so using mpich)

https://buildd.debian.org/status/fetch.php?pkg=mumps&arch=hppa&ver=5.8.2-1&stamp=1777034697&raw=0

=== running c_example (serial) ===
Fatal error in internal_Allreduce: Invalid communicator, error stack:
internal_Allreduce(142): MPI_Allreduce(sendbuf=0xf947dfd0, recvbuf=0xf947dfc8, count=1, MPI_2INTEGER, MPI_MINLOC, comm=0x0) failed
internal_Allreduce(45).: Invalid communicator
[unset]: PMIU_write error; fd=-1 buf=:cmd=abort exitcode=67710469 message=abort
:
system msg for write_line failure : Bad file descriptor

Debugging c_example.c show the error is occuring during the main dmumps_c run
(analyse, factorization and solve) id.job=6  at l.82,
  /* Call the MUMPS package (analyse, factorization and solve). */
  id.job=6;
  dmumps_c(&id);


The same mumps code is running successfully with mpich on armf, i386
(including hurd) and x32, so it's hard to argue that it's a bug in
mumps itself.

Is it a bug in the hppa support of mpich?

I can conditionally get a successful mumps tests run on hppa with some
manuipulation of the lib dir (LD_LIBRARY_PATH) used with the
build-time tests.

That suggests the problem is arising through the complexity of the
MUMPS build system. It is quite archaic, still based directly on make
and using a Makefile.inc fragment to control the various build
options. The destination dir for the libraries is set to ./lib, which
debian/rules the copies to various lib* subdirs for the various
package variants.

I can get a successful test run by just using lib alone, i.e. just
building tests for the last configuration case. That suggests the hppa
build is getting confused about which library configuration is which,
and running tests with the wrong one. Apparently other architectures
don't get the libraries confused like this.

A corollary is that the mpich might be fine on hppa.
The problem here is the complexity of the MUMPS build system running
with different build configurations.

Don't know, but did you take into account that hppa is 32-bit big-endian.
I see quite many warning like this:
warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘int64_t’ {aka ‘long long int’} [-Wformat=]

This is quite dangerous.
On little-endian machines (armf, i386, x32..) %d will print the (correct) lower 32-bits.
But on hppa (big-endian), %d will print the (wrong) upper 32-bits of the int64_t.

Just a guess....

Helge

Helge Deller wrote:

That's a good point.  They do have a configuration option
-DNO_64BIT_ADDRESSES_IN_C

I'll try and see if it helps.

That's good thinking that the issue might be related to 32-bit
bigendian. You're likely right about that.

mumps does have a -DNO_64BIT_ADDRESSES_IN_C configuration option
intended to fix some 64-bit addressing issues.
Unfortunately it's not enough on its own to get a successful build.
I guess they didn't provide it to deal with endian issues.