Re: double handling of BLAS alternatives: blas.so vs blas.so.3
On Wed, 2021-05-05 at 14:57 +0200, Drew Parsons wrote:
>
>
> 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.
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)).
As specifying `libblas.so` without SOVERSION would very likely trigger
a lintian Error, I think all blas/lapack reverse dependencies won't
care about at which implementation on earth is symlink libblas.so
pointing. I think this applies to all ELF binaries in the Debian
archive.
Of course, FFI/dlopen is not the case to discuss here.
> > 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?
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?
Reply to: