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
