[Python-modules-team] Bug#914655: Bug#929296: libopenblas-base: is libopenblas.so needed?
dparsons at debian.org
Tue May 21 10:13:35 BST 2019
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
as suggested at
More information about the Python-modules-team