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 <[email protected]> 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 [email protected]. >
