There is a mistake in the patch openblas-0.3.12-shared-blas-lapack.patch and in the section to generate libcblas.so.3 we have ``` +libcblas.so.3: $(CSBLAS1OBJS) $(CSBLAS2OBJS) $(CSBLAS3OBJS) $(CDBLAS1OBJS) $(CDBLAS2OBJS) $(CDBLAS3OBJS) $(CCBLAS1OBJS) $(CCBLAS2OBJS) $(CCBLAS3OBJS) $(CZBLAS1OBJS) $(CZBLAS2OBJS) $(CZBLAS3OB> + $(CC) $(LDFLAGS) -shared -o $@ $^ -Wl,-soname,libblas.so.3 -L.. -lopenblas $(EXTRALIB) ``` which means that /usr/$(get_libdir)/blas/openblas/libcblas.so.3 get libblas.so.3 as its soname. This in turn prevents ldconfig to cache the library properly. ldconfig complains during the postinstall phase of the ebuild by spitting the following non-fatal message: /sbin/ldconfig: /usr/lib64/blas/openblas/libblas.so.3 is not a symbolic link But because the library is not cached, the reference implementation of cblas is used even if openblas is eselected - for example fbissey@moonloop ~ $ ldd -r /usr/lib64/libgsl.so linux-vdso.so.1 (0x00007ffcb79c6000) libcblas.so.3 => /usr/lib64/libcblas.so.3 (0x00007fefc9fa5000) libm.so.6 => /lib64/libm.so.6 (0x00007fefc9e70000) libc.so.6 => /lib64/libc.so.6 (0x00007fefc9cb5000) libblas.so.3 => /usr/lib64/blas/openblas/libblas.so.3 (0x00007fefc9c54000) /lib64/ld-linux-x86-64.so.2 (0x00007fefca25e000) libopenblas.so.0 => /usr/lib64/libopenblas.so.0 (0x00007fefc8f04000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fefc8ee4000) libgfortran.so.5 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgfortran.so.5 (0x00007fefc8c20000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libquadmath.so.0 (0x00007fefc8bd6000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgcc_s.so.1 (0x00007fefc8bbc000) As can be seen libcblas.so.3 is resolved to /usr/lib64/libcblas.so.3 instead of /usr/lib64/blas/openblas/libcblas.so.3. libopenblas is still loaded because /usr/lib64/libcblas.so.3 loads libblas.so.3 which is correctly resolved to /usr/lib64/blas/openblas/libblas.so.3. Correcting the typo in the patch fix all those issues. Reproducible: Always
damn... Well, thankfully its a quick fix.
And the CRAZIEST thing about this is that even if CBLAS functions from /usr/lib64/libcblas.so.3 are used, they are actually wrappers to libblas.so.3 functions, which it then loads from /usr/lib64/openblas/libblas.so.3. So there is literally no way to detect this during runtime by checking speed of code :O Amazing!
After I started talking about .la files and what not, some people have been paying attention and reported stuff to me (https://github.com/cschwan/sage-on-gentoo/issues/609). I must say, I always wanted to return to that strange message when from ldconfig. But as always, if you don't do it on the spot, you forget. And of course the way the message related to the mistake was not obvious. libblas looks completely normal. Who would have thought to look at libcblas for a message on libblas.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=59a6f386a6aed06fde78eb6fdc48f31a0de520ca commit 59a6f386a6aed06fde78eb6fdc48f31a0de520ca Author: Aisha Tammy <gentoo@aisha.cc> AuthorDate: 2020-11-07 11:24:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-11-08 00:56:12 +0000 sci-libs/openblas: fix libcblas soname Closes: https://bugs.gentoo.org/753437 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Aisha Tammy <gentoo@aisha.cc> Closes: https://github.com/gentoo/gentoo/pull/18171 Signed-off-by: Sam James <sam@gentoo.org> sci-libs/openblas/files/openblas-0.3.12-shared-blas-lapack.patch | 2 +- sci-libs/openblas/{openblas-0.3.12.ebuild => openblas-0.3.12-r1.ebuild} | 0 2 files changed, 1 insertion(+), 1 deletion(-)
