Re: double handling of BLAS alternatives: blas.so vs blas.so.3
Hi Drew,
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.
> 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.
The separation is intended for the build/run-time.
When we build packages based on BLAS/LAPACK, it requires a virtual
build-dependency libblas.so which can be filled by libblas-dev, etc.
During the linking stage, that alternative would be resolved into,
e.g., libblas-dev::.../libblas.so -> libblas3::.../libblas.so.3,
and the resulting ELF will NEED (readelf) a libblas.so.3 .
If you encounter an ELF binary that NEED libblas.so without
specifying the SOVERSION, this ELF binary is exactly a true disaster.
> It seems inconsistent with the way the unversioned library is handled
> in
> "normal" libraries, where it simply points at the latest versioned
> library. Shouldn't the blas framework be doing the same thing, with
> a
> simple local symlink /usr/lib/<arch>/libblas.so ->
> /usr/lib/<arch>/libblas.so.3 ? Then the blas alternatives would only
> need to handle libblas.so.3.
> /usr/lib/<arch>/libblas.so -> /usr/lib/<arch>/libblas.so.3 could be
> handled by a libblas-common-dev package that all blas dev packages
> depend on (since libblas-dev is the reference implementation.
> Actually
> maybe libblas-dev should be retooled as the common package, and the
> reference implementation made explicit as libblas-reference-dev. That
> could help make it more clear that you probably do not want to
> install
> libblas-reference-dev for actual numerical work).
>
> What is the motivation for setting up libblas.so as an alternative
> separate from libblas.so.3 ? It makes BLAS installation management
> more
> difficult, I think.
Having been away from Debian for a while, currently I do not fully
recall the reasons ... but actually the libblas.so alternative
is also associated with header files and static libs that differ
across providers.
Reply to: