<div dir="ltr"><div>it sounds reasonable to drop the multiarch setting for libgmm-dev as is the case for libgetfem-dev.</div><div><br></div><div>In general though, I think this is just the tip of the BLAS iceberg. The observed switching in the detected <span class="gmail-im">GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT suggests that</span> the update-alternatives for libblas/liblapack is probably broken for certain combinations of architecture and blas provider, see e.g.:</div><div><br></div><div><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732</a></div><div><br></div><div>Kostas</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 15 Jun 2026 at 19:21, Drew Parsons <<a href="mailto:dparsons@emerall.com">dparsons@emerall.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2026-06-15 13:12, Graham Inggs wrote:<br>
> <br>
> I don't think this bug is related to build failures on non-release<br>
> architectures.<br>
...<br>
> $ diffoscope  libgmm-dev_5.5+dfsg1-1_amd64.deb <br>
> libgmm-dev_5.5+dfsg1-1_s390x.deb<br>
> <br>
> │ │ │  /* defined if the BLAS fortran ABI does not return complex<br>
> values directly (e.g. Intel's MKL) */<br>
> │ │ │ -/* #undef GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT */<br>
> │ │ │ +#define GMM_BLAS_RETURN_COMPLEX_AS_ARGUMENT /**/<br>
<br>
Good catch, thanks Graham.  I'll try to understand why BLAS is getting <br>
different treatment from libgmm here<br>
I wouldn't have thought this particular point would be endian-sensitive, <br>
but perhaps it is.<br>
<br>
If it's normal to get different BLAS behaviour here, then it'll be <br>
simplest to just drop the multiarch field.<br>
<br>
Drew<br>
<br>
-- <br>
To unsubscribe, send mail to <a href="mailto:1133815-unsubscribe@bugs.debian.org" target="_blank">1133815-unsubscribe@bugs.debian.org</a>.<br>
</blockquote></div>