Bug#1133815: libgmm-dev fails to coinstall

[Konstantinos Poulios]

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.


On Tue, 16 Jun 2026 at 11:21, Drew Parsons <dparsons at debian.org> wrote:

> Source: getfem
> Followup-For: Bug #1133815
>
> 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.
>
> --
> To unsubscribe, send mail to 1133815-unsubscribe at bugs.debian.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20260616/ec531d57/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 63512 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20260616/ec531d57/attachment-0001.png>