[Python-modules-team] Bug#914655: 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 Python-modules-team
mailing list