<div dir="ltr"><div dir="ltr">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.</div><div dir="ltr"><br></div><div>Anyway to resolve the present bug, removing Multi-arch from libgmm-dev is a good solution, as we discussed.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 16 Jun 2026 at 12:36, 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-16 12:16, Konstantinos Poulios wrote:<br>
> <br>
> Going beyond this specific bug, the main issue is that BLAS has an<br>
> ambiguous API/ABI. What I am pointing out is that AFAIK<br>
> update-alternatives cannot deal with such ambiguities. Right?<br>
<br>
Not exactly.  The alternatives are for each architecture,<br>
so if they are consistent within each, then there is no conflict.<br>
<br>
That is, s390x might be different from other architectures,<br>
but so long as openblas, blis etc are using the same interface as <br>
reference BLAS,<br>
there should be no problem.<br>
<br>
> At least for mkl, it leads to errors as reported in<br>
> <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067732</a> , but based<br>
> on the confb.cpp test results shown by Drew, I would not be surprised<br>
> if there are more undiscovered bugs related to complex number blas.<br>
<br>
This is indeed a serious conflict, if intel-mkl is handling the <br>
interface differently<br>
from the other implementations.  The bug is rightly placed with the <br>
intel-mkl package.<br>
A great pity if intel-mkl is necessarily incompatible; I had thought the <br>
BLAS ABI had been<br>
standardised sufficiently to avoid that.<br>
</blockquote></div></div>