Re: double handling of BLAS alternatives: blas.so vs blas.so.3

[Drew Parsons <dparsons@debian.org>]

On 2021-05-04 10:49, Sébastien Villemot wrote:
> Hi Drew and Mo,
>
> Le mardi 04 mai 2021 à 05:25 +0000, M. Zhou a écrit :
> > On Sun, 2021-05-02 at 13:50 +0200, Drew Parsons wrote:
> > > Mo Zhou did the good work of setting up an alternatives framework for
> > > our BLAS libraries, which is great. We can select between OpenBLAS,
> > > BLIS, whatever is best for the local system (even intel-mkl).
> >
> > Actually that alternative system is NOT my original work -- I just
> > refined it with BLAS64 alternatives along with some minor enhancements
> > IIRC. Only Gentoo's initial version of BLAS/LAPACK switching is
> > my original work.
>
> I confirm that this setup is very old, i.e. at least 10 years, maybe
> more. It also predates my involvement in the BLAS/LAPACK ecosystem.


Thanks for the correction.  It was the 64-bit builds that Mo Zhou got 
working for us (and thank you for that).


> > > But the framework was set up with double handling of the basic
> > > libblas.so alternative symlink in each /usr/lib/<arch> directory. 
> > > There's one for the unversioned libblas.so, and a separate one for
> > > libblas.so.3.
> > >
> > > This means it's possible for the libblas.so alternative to point at
> > > blis-pthread/libblas.so, for instance, while libblas.so.3 points at
> > > openblas-pthread/libblas.so.3. It seems to me that's a potential for
> > > disaster.
>
> While I agree that the separation between libblas.so and libblas.so.3
> is a bit confusing, I don’t see where is the “potential for disaster”.


The "disaster" is that they can point to different implementations. So 
if you check the symlinks for libblas.so, you think you're using one 
implementation, while the different libblas.so.3 means  you're actually 
running against another implementation.  So it's not a build disaster as 
such, since they keep ABI compatibility.  But it is a system maintenance 
disaster in the sense that it makes it harder than it needs to be to 
keep track of which BLAS is actually running on the system.

...

> The libblas.so alternative only matters when you’re doing static
> linking, since that alternative also governs libblas.a. But we don’t
> use static linking much in Debian. And for someone who is doing static
> linking, the libblas.so.3 alternative is irrelevant anyways, so there
> is no risk of confusion.

OK, if libblas.so controls libblas.a, then it's more meaningful.  Though 
still odd to have static symbols handled by one implementation, and 
dynamic symbols by another.  Are there any cases where that would be 
desirable?

Drew