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 On Mon, 15 Jun 2026 at 19:21, Drew Parsons <[email protected]> wrote: > On 2026-06-15 13:12, Graham Inggs wrote: > > > > I don't think this bug is related to build failures on non-release > > architectures. > ... > > $ diffoscope libgmm-dev_5.5+dfsg1-1_amd64.deb > > libgmm-dev_5.5+dfsg1-1_s390x.deb > > > > │ │ │ /* 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 /**/ > > 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 > > -- > To unsubscribe, send mail to [email protected]. >
