Hi Drew, I didn't closely investigate into the scipy bug, but I can answer some of your questions. BTW, does anything break in a clean chroot? I mean, making sure a thing works fine in an unclean environment is difficult.
On 2019-05-21 04:57, Drew Parsons wrote: > Why is /usr/lib/x86_64-linux-gnu/libopenblasp-r0.3.5.so provided by > libopenblas-base? Julia links against libopenblas.so.0 instead of libblas.so / liblapack.so . Julia's linear algebra standard library is not quite ready for library switching. > The problem is that libopenblasp-r0.3.5.so contains exactly the same > symbols as libblas.so and liblapack.so. This seems to be confusing > linkers, e.g. see Bug#914655 for python-scipy. The Debian dependency template resolving of the BLAS / LAPACK family is designed to work like this: - linked against libblas.so.3 -> enable alternative, resolve to libblas.so.3 | libblas.so.3 - linked against libopenblas.so.0 -> tight requirement on openblas, resolve to libopenblas-base Even if libopenblas.so.0 contains the same set of symbols as (libblas.so.3 + liblapack.so.3 + some extended routines), the SONAME matters for our dependency tree. > If libopenblasp-r0.3.5.so is present then it is used preferentially to > provide BLAS and LAPACK symbols, so the shared library > (_flapack.x86_64-linux-gnu.so in the case of python-scipy) ends up with > NEEDED libopenblas.so.0 > instead of > NEEDED liblapack.so.3 > NEEDED libblas.so.3 libopenblasp-r0.3.5.so should never be used as BLAS / LAPACK provider as it's SONAME unmatches the depencency template and would incur breakage to our dependency tree. If a program is really linked against libopenblas.so.0, liblapack.so.3, and libblas.so.3, it is still problematic as symbol clashes between (possibly) different implementations may lead to unexpected results. > The official builds of scipy are fine since they build against the > generic BLAS. But local builds can become confused, which is what I > think happened with Bug#914655. The package Depends: libblas3 | > libblas.so.3 where in this case it would need Depends: libopenblas-base. > > So, is libopenblasp-r0.3.5.so really supposed to be provided in > /usr/lib/x86_64-linux-gnu by libopenblas-base, or this a bug which > should be fixed when the various BLAS flavours are being expanded? I'm sure libopenblasp-r0.3.5.so cannot be removed. Every OpenBLAS flavor will ship 3 shared objects: openblas-flavor/libopenblas*.so.* SONAME: libopenblas.so.0 openblas-flavor/libblas.so.3 SONAME: libblas.so.3 openblas-flavor/liblapack.so.3 SONAME: liblapack.so.3
