libgmm-dev is declared Multi-Arch: same, but fails to coinstall.

The file /usr/include/gmm/gmm_arch_config.h is shared by libgmm-dev
version 5.4.4+dfsg1-5 as present in trixie and version 5.4.4+dfsg1-6 as
present in forky|unstable with varying content.

Please ensure that shared files have bit-identical content across
architectures, move architecture-dependent files to
architecture-dependent paths or remove the Multi-Arch: same field.

Kind regards

Helmut Grohne

I guess this is due to the recent disabling of MUMPS on some architectures:

https://salsa.debian.org/science-team/getfem/-/commit/f19b5be52a5820bcac2a4be621e0c9897d8ca79d

any chance that MUMPS will soon be available on all architectures?

The mumps build failure is in the nonofficial arches
hppa and powerpc, so broken support for them can't be considered
a RC bug.  Hence reducing the severity of this bug to normal.

The MUMPS build failure on these arches has been long standing, which
is why I updated getfem to work around the problem.  I don't see it
being fixed any time soon but I'll bring it to upstream's attention.

The failure is in the MUMPS buildtime tests. One option is to skip the
tests on hppa and powerpc. But the test failure is comprehensive, the
tests do not even nearly work. So it's not clear that providing a
mumps package that is known to not work is useful for any purpose
other than closing this bug.  I guess you could justify ignoring
MUMPS's own test failures if getfem could be shown to pass its tests
using MUMPS on hppa and powerpc.

The mumps failure on hppa/powerpc is subtle.
The segfault is reproducible, but also hard to interpret:
it happens at "address 0x00" before the mumps test program even
executes.

Running the test with mpich gives a hint: there is a reference to
unsupported PMIX.  Indeed libpmix supports 64-bit architectures only.
mpich is not supposed to use it on 32-bit hppa or powerpc. And yet it
is using it. Evidently there is something wrong with the system
configuration for the mpich builds on hppa and powerpc, and that error
is flowing on to mumps.

Hi
architectures.

I compared some of the libgmm-dev binary packages and found the
following difference:

$ diffoscope  libgmm-dev_5.5+dfsg1-1_amd64.deb libgmm-dev_5.5+dfsg1-1_s390x.deb

│ │ ├── ./usr/include/gmm/gmm_arch_config.h
│ │ │ @@ -25,11 +25,11 @@
│ │ │  /* defined if superlu header files are not under a subdirectory
called "superlu" */
│ │ │  /* #undef GMM_NO_SUPERLU_INCLUDE_SUBDIR */
│ │ │
│ │ │  /* Use blas with 64 bits integers */
│ │ │  /* #undef GMM_USE_BLAS64_INTERFACE */
│ │ │
│ │ │  /* defined if the BLAS fortran ABI does not return complex
values directly (e.g. Intel's MKL) */
│ │ │ -/* #undef GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT */
│ │ │ +#define GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT /**/
│ │ │
│ │ │  /* GMM version */
│ │ │  #define GMM_VERSION "5.5"

One solution is to simply drop the Multi-Arch: same field from the
libgmm-dev binary package (only).  See a similar bug reported against
libtrilinos-kokkos-kernels-dev  [1].

Regards
Graham


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1133738

...

Good catch, thanks Graham.  I'll try to understand why BLAS is getting
different treatment from libgmm here
I wouldn't have thought this particular point would be endian-sensitive,
but perhaps it is.

If it's normal to get different BLAS behaviour here, then it'll be
simplest to just drop the multiarch field.

Drew

it sounds reasonable to drop the multiarch setting for libgmm-dev as is the
case for libgetfem-dev.

In general though, I think this is just the tip of the BLAS iceberg. The
observed switching in the detected GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT
suggests that the update-alternatives for libblas/liblapack is probably
broken for certain combinations of architecture and blas provider, see e.g.:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732

Kostas

Hi Graham,

I concur. This bug is not about powerpc or hppa. Hence removing the
block relations.

I concur. Therefore libgmm-dev violates current Debian policy on a
release architecture. The appropriate severity is serious.

Yes. Droping M-A:same is a sensible resolution of this bug. It is a
small minority of lib*-dev packages that need to be M-A:same and I doubt
this to be needed for libgmm-dev. If there is such a need, more effort
can be invested into the header.

Helmut

To get some more context, I ran the configure.ac tests standalone on
the s390x porterbox

confb.cpp
-------------------------------------
#include <cstdio>
#include <complex>
#if defined(GMM_USE_BLAS64_INTERFACE)
  #define INT long
#else
  #define INT int
#endif
extern "C" {
void cdotu_(std::complex<float>*, const INT*, const std::complex<float>*, const INT*,
            const std::complex<float>*, const INT*);
}
int main() {
    const INT one=1;
    std::complex<float> x(1.,2.), y(1.,-2.), result;
    cdotu_(&result, &one, &x, &one, &y, &one);
    printf("result (bad C)=%g + %gi\n", result);
    printf("result (complex comp)=%g + %gi\n", real(result), imag(result));
    printf("result.real()=%g\n", result.real());
    printf("result.real()-5.=%.20f\n", result.real()-5.);
    printf("fabs(result.real()-5.)=%.20f\n", fabs(result.real()-5.));
    printf("fabs(result.real()-5.)< 1e-8 = %d\n", fabs(result.real()-5.)<1e-8);
    printf("returning %d\n", (fabs(result.real()-5.) < 1e-8) ? 0 : 1);
    return (fabs(result.real()-5.) < 1e-8) ? 0 : 1;
}
-------------------------------------

$ g++ -o confb confb.cpp -lblas

Executing on s390x:
$ ./confb
result (bad C)=0.0078125 + 0.00781251i
result (complex comp)=5 + 0i
result.real()=5
result.real()-5.=0.00000000000000000000
fabs(result.real()-5.)=0.00000000000000000000
fabs(result.real()-5.)< 1e-8 = 1
returning 0


The issue is that result.real() returns 5 on s390x, which apparently
is the same as Intel fortran.

By contrast result.real() returns 0 on amd64, so the test in
configure.ac identifies amd64 as gnu-type not intel-type.
Executing on amd64:
$ ./confb
result (bad C)=0 + 6.95048e-310i
result (complex comp)=0 + 0i
result.real()=0
result.real()-5.=-5.00000000000000000000
fabs(result.real()-5.)=5.00000000000000000000
fabs(result.real()-5.)< 1e-8 = 0
returning 1

I don't think the BLAS implementations or debian blas alternatives are
the problem.  This is the reference blas (libblas-dev). You might
argue there's a misconfiguration in the BLAS packages (or in gfortran)
for s390x. But BLAS otherwise seems to be working fine, we're not
seeing other BLAS errors coming from s390x.

The difference seems to be way that getfem is using BLAS,
which evidently requires arch-specific handling.  Since this
difference is reflecting in the headers via the definition of
GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT, we've got the situation leading
to this bug report.

The difference appears to be real for getfem, not a bug (unless someone can
identify an s390x bug in BLAS or gfortran).
In that case dropping the multiarch field is best, which Konstantinos
is doing in salsa MR.

yes, exactly that's what I imagined. Both amd64 and s390x builds use the
reference blas from libblas-dev. However, on s390x the blas package behaves
as intel-type while on amd64 it behaves as gnu-type:

[image: image.png]

GetFEM's configure.ac does the only reasonable thing, it detects the ABI of
the linked BLAS and adapts itself to it by
setting GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT.

Going beyond this specific bug, the main issue is that BLAS has an
ambiguous API/ABI. What I am pointing out is that AFAIK update-alternatives
cannot deal with such ambiguities. Right?

At least for mkl, it leads to errors as reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732 , but based on
the confb.cpp test results shown by Drew, I would not be surprised if there
are more undiscovered bugs related to complex number blas.

Not exactly.  The alternatives are for each architecture,
so if they are consistent within each, then there is no conflict.

That is, s390x might be different from other architectures,
but so long as openblas, blis etc are using the same interface as
reference BLAS,
there should be no problem.

This is indeed a serious conflict, if intel-mkl is handling the
interface differently
from the other implementations.  The bug is rightly placed with the
intel-mkl package.
A great pity if intel-mkl is necessarily incompatible; I had thought the
BLAS ABI had been
standardised sufficiently to avoid that.

Ofc there will be no issue with update-alternatives if blas alternatives
are indeed consistent within each architecture. I just doubt this is the
case. It would be worth checking.

Anyway to resolve the present bug, removing Multi-arch from libgmm-dev is a
good solution, as we discussed.

We believe that the bug you reported is fixed in the latest version of
getfem, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1133815@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Drew Parsons <dparsons@debian.org> (supplier of updated getfem package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 19 Jun 2026 12:32:34 +0200
Source: getfem
Architecture: source
Version: 5.5+dfsg1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers <debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Drew Parsons <dparsons@debian.org>
Closes: 1133815
Changes:
 getfem (5.5+dfsg1-2) unstable; urgency=medium
 .
   [ Konstantinos Poulios ]
   * Team upload.
   * Drop Multi-Arch from libgmm-dev. Closes: #1133815
   * Fix upstream metadata
   * Remove outdated python import fix
   * Remove outdated gmm arch header file fix
   * Fix copyright data
Checksums-Sha1:
 24f2e8d9fe9ce503f25810482e39de2a7d0ff8e8 2754 getfem_5.5+dfsg1-2.dsc
 f652a708c0dda88642b2d44934cbd6856eaffb16 11360 getfem_5.5+dfsg1-2.debian.tar.xz
 87dbb36fe0a099a275acb68a81e19a3f62a08a1c 13136 getfem_5.5+dfsg1-2_amd64.buildinfo
Checksums-Sha256:
 1c9a8b25b6304e496ac8b4b59385d7b6639304af3d90b601b1efc97fb0608236 2754 getfem_5.5+dfsg1-2.dsc
 d8b07adfe17f229ee7b0a9f8be7462775c289ebc8e5c6a179374df84ab374b05 11360 getfem_5.5+dfsg1-2.debian.tar.xz
 5af4d1171f5ba6e7a9e355277acb72ea648243e5eab7d0bb4c1e73b8e05fad2a 13136 getfem_5.5+dfsg1-2_amd64.buildinfo
Files:
 856b35e5cabddb575e55ac2a49e18db3 2754 libs optional getfem_5.5+dfsg1-2.dsc
 822d6b0fa23e15dc5a550f65f87cdb5f 11360 libs optional getfem_5.5+dfsg1-2.debian.tar.xz
 0b53d7045265d770e23b4895ca20e65a 13136 libs optional getfem_5.5+dfsg1-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEI8mpPlhYGekSbQo2Vz7x5L1aAfoFAmo1JZoACgkQVz7x5L1a
Afpi1w/+KvnB7xF+rlyJj1V97lByN761b6iwFFHRR3/2tJXIqdlwx6GrdsRif+zY
CtD1DOy99yIFI4LrIKRo3WoCMAmJHvHAHlirMvrwZkGmqPxcPVo4NyJxPzKyuG3n
5EQP4OYVb+Vhu8YT09QxHiO0ttKBpikI16MUM7NGzic+nzDslma3kcvJz4LrCTB+
xG3wBHNN5Z0LmChk887DWpBncvidLqD+0OuJWZYiOK4gjKoTtl5qTImXK0PCK2GI
12G6cpasxyaac6rOMQB2jBoOergquK8w+0X+vhXzMTZSWggztfpJoAYyoN9ej27W
Xx7+u8akWLDUSvf1PkSjYgSBQ/NxO090VU5bq8U874SUCXJildddqNp8WClWQ79i
cZLVq/X2oldAQDiGxR8mTX/c7dDfJnZ/a3wPZM1WCSm/UJ+9bp8sMdUalo3LcyVy
fUpN6Anw4S3BKhF9vy416OKK9BmK7xBQ05elnoADRp62vLlEWr2YslEM4yd2c6gx
G70txKjbC1hBpeQbPa8qMMJt/K0Y73YGSwOsZeA+KA/FjQQiFnfyobwRd1Sv/458
wfbzTQ/yih0W9ZM1UiLJ7DvKyoxOJg3jelGNRAYFm2I37MMuirsL/gN3LiaUqCVQ
D2Ygi+V63d6abQVyS8TbeSjH4fMIU9FfbzOzm0Qm9AJgt2BCJEc=
=nxp/
-----END PGP SIGNATURE-----