double handling of BLAS alternatives: blas.so vs blas.so.3
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).
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.
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.
Drew
Reply to: