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

[Drew Parsons <dparsons@debian.org>]

On 2021-05-06 14:43, M. Zhou wrote:

On Wed, 2021-05-05 at 14:57 +0200, Drew Parsons wrote:

 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.

A sensible way to check which implementation is actually used is to
follow the logic of the dynamic linker (see ld.so(8) and elf(5)).
It loads libraries specified by the ELF header as NEEDED (readelf)
or DT_NEEDED (ld.so(8), elf(5)).

 

True at the detailed binary level, though not so convenient for routine system maintenance.

 

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?

There may be room for further improvement. But the first question
came up in my mind is: how to manage differnt header files (e.g.
cblas.h) and static libs exported by different implementations
without introducing further confusions?

For example, BLAS implemtations (except for BLIS and MKL) in our
archive provide libblas.a. When we switch BLAS to BLIS or MKL,
that libblas.a symlink exposed under /usr/lib/<triplet>/ will
be automatically hidden, and the linker won't find it from the
default search path. So users won't accidentally make

Without the current alternatives mechanism, can we find a better
solution to avoid the situation where the libblas.a from the
reference implementation and the cblas.h header from MKL are
exposed at the same time?

That helps me understand the current situation.  The question of cblas.h certainly complicates any simpler solution, especially since we're trying to eliminate it anyway.

But I'm coming to understand that handling libblas.a is the real underlying motivation for the two blas alternatives (libblas.so and libblas.so.3. That is, even though it's identified as libblas.so, really that alternative is about libblas.a, not libblas.so.  I missed that point initially since I'm currently Preferring blis, so I don't see any /usr/lib/<triplet>/libblas.a.   I had assumed it was general treated as "deprecated".

My first thought was that libblas.so could just be a common direct symlink to libblas.so.3, no alternative needed.  But that won't address libblas.a alternatives.  My second thought was that the libblas.so (libblas.a) alternatives could be slaves to libblas.so.3 so there's only one alternative to set.  But that doesn't work since one is "libblas-dev" and the other is "libblas3", different packages, and of course libblas3 can be installed without libblas-dev.

So maybe what we've got is the best we can do, in order to handle both libblas.a and libblas.so.3.
Only two other options to consider:

1) Can an indentured servant (not "slave") alternative be set up for libblas.so, that trackes libblas.so.3  What I have in mind is the way an alternative for hdf5-mpi.pc is set, which is configured contingent on the alternative for mpi (see libhdf5-openmpi-dev.postinst).  It's not completely stable however, and won't be automatically updated if the system adminstrator changes the preferred mpi (it gets refreshed whenever libhdf5-openmpi-dev is reconfigured or updated).

2) Since the libblas.so alternative is not actually about libblas.so, should it just be renamed to libblas.a?   Then it would be more correct about what the alternative is for. Or rename as cblas.h, if that' more key than libblas.a?  (I'm curious to know why libblis.a can't link in place of libblas.a. It has the blas symbols doesn't it, as well as other symbols?)

Drew