On 2019-05-21 14:41, Mo Zhou wrote:
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.
It seems fine in a clean chroot. In that case tt links against
liblapack.so.3 as it should.
On 2019-05-21 04:57, Drew Parsons wrote:
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.
...
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.
This seems to be the problem. libopenblas.so.0 is used to resolve
symbols instead of liblapack.so.3. The symbol in question in Bug#914655
is ilaver_ which is part of lapack, not specific to libopenblas.
Perhaps our scipy build should explicitly avoid libopenblas.so by
setting
export BLAS=/path/to/libblas.so
export LAPACK=/path/to/liblapack.so
as suggested at
http://scipy.github.io/devdocs/building/linux.html#specific-instructions
