http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c10 --- Comment #10 from Egbert Eich <eich@suse.com> --- (In reply to Stefan Brüns from comment #8)
1. openBLAS is not available for RISC-V, and likely never will 2. directly linking to openblas_* forfeits the possibility to use a different BLAS/LAPACK implementation. 3. Netlib (c)blas + lapack is ~0.7 + 7 MByte, openblas is ~28 MByte.
Right.
Right. libopenblas is not a provider of libblas.so.3..., libcblas.so.3..., liblapack.so.3... either.
It does not provide the SONAME, so it is not picked up on the RPM level. The same is true for any other BLAS implementation I am aware of. But thats orthogonal to the question whether it is picked up as a runtime provider using update-alternatives.
As long as some file/symlink named libblas.so.3 is in the runtime linker path (either ld.conf* or LD_LIBRARY_PATH), it will be picked up, even if it is a library with a completely different SONAME and file name.
Sure. Your changes to lapack looked fine. I've sent them on to Factory. I cannot accept your drop request for science/CBLAS, yet, as it is still the devel project for Factory. I've filed a separate drop request for that. The priorities of liblapack, libblas and libcblas from the netlib lapack are higher than for the ones from openblas. Thus, even if openblas is installed, it will not be picked up automatically. Do you prefer it this way? While looking at this, I've noticed there are no update-alternatives for the lapack C interface. openblas does provide this as well, though. It should probably be added. -- You are receiving this mail because: You are on the CC list for the bug.