[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: double handling of BLAS alternatives: blas.so vs blas.so.3



Hi Drew and Mo,

Le mardi 04 mai 2021 à 05:25 +0000, M. Zhou a écrit :
> 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.

I confirm that this setup is very old, i.e. at least 10 years, maybe
more. It also predates my involvement in the BLAS/LAPACK ecosystem.

> > 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.

While I agree that the separation between libblas.so and libblas.so.3
is a bit confusing, I don’t see where is the “potential for disaster”.

My understanding is that it makes no difference whether libblas.so 
points to reference BLAS or OpenBLAS or whatever, as long as you’re
doing dynamic linking. Since all those libraries are ABI-compatible,
the resulting executable will be the same in all cases (with
libblas.so.3 in the NEED section of the ELF binary).

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.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: