Bug#929296: libopenblas-base: is libopenblas.so needed?

Mo Zhou lumin at debian.org
Tue May 21 12:55:42 BST 2019


On 2019-05-21 09:13, Drew Parsons wrote:
> 
> 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.

ilaver_ is indeed a standard fortran routine provided in lapack.
The scipy package in archive looks good:

dpkg -L python3-scipy | rg '.*.so$' | xargs readelf -d | grep NEEDED |
sort | uniq

> 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

Sounds good to me if exporting these environment variables solves the
problem.
But what happens during run time? Will scipy mix the usage of
(libopenblas.so) and (libblas.so + liblapack.so) ?



More information about the debian-science-maintainers mailing list