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.
