[Python-modules-team] Bug#914655: Bug#929296: libopenblas-base: is libopenblas.so needed?

[Drew Parsons]

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