Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)

[Jochen Sprickerhof]

Hi Sébastien,

* Sébastien Villemot <sebast...@debian.org> [2022-12-16 10:30]:

Le jeudi 15 décembre 2022 à 21:16 +0100, Paul Gevers a écrit :

On 13-12-2022 21:59, Sébastien Villemot wrote:
> The problem is that atlas needs to be recompiled against lapack 3.11.0.
> Which has been done in atlas 3.10.3-13. But atlas itself cannot migrate
> to testing because of #1025699.

While I understand recompiling "solves" the issue, normally this error
"undefined reference" hints at removal of symbols. Normally that should
be handled by a SONAME bump which would trigger auto trackers to be
generated for the transition. Such trackers notify the release team of
transitions and they can trigger rebuilds (you know that drill,
including the transition bug filing for coordination). Why do you think
that a SONAME bump wasn't the right solution in this case?

Actually the error is not due to a symbol removed, but to a symbol
*added*. So no SONAME bump is warranted.

Let me explain:

In lapack 3.11.0, several new symbols ({z,c,d,s}trsyl3_) were added to
liblapack.so.3 (a linear algebra library with a Fortran interface).
As a consequence, new wrapper functions around these symbols were also
added to liblapacke.so.3 (note the “e”), which is a C wrapper around
liblapack.so.3, and which is also shipped by src:lapack. Hence the
latest liblapacke.so.3 depends on the new symbols in liblapack.so.3.

Now, libatlas3-base (compiled from src:atlas) also provides its own
version of liblapack.so.3 (through the alternatives system¹). But,
until it is recompiled against lapack 3.11.0, that version of
liblapack.so.3 does not contain the new symbols. Hence, when
liblapack.so.3 is provided by libatlas3-base, loading liblapacke.so.3
produces the error that is seen in the failing test.

Essentially, what is missing is a restriction which would forbid the
co-installation of liblapacke ⩾ 3.11 and libatlas3-base compiled
against lapack < 3.11. I don’t know how to express that using our
tooling, but maybe I’m unimaginative.

I think you can get that with a virtual abi package, something like:

Provides: libblas-abi (= 3.11)

And have downstream packages shlibs depend on that virtual package:

override_dh_makeshlibs:
        dh_makeshlibs -plibfoo -V 'libblas-abi (= 3.11)'
        dh_makeshlibs --remaining-packages

Maybe also add a:

Conflicts: libblas-abi (= 3.11)



Cheers Jochen

So only one lib can be installed at the same time and drop the alternatives system.

signature.asc
Description: PGP signature