Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
* Sébastien Villemot [2022-12-16 16:26]: In the current system, in which the BLAS and LAPACK implementation are decided through the alternatives system, it’s not possible to solve the problem through versioned provides. Because even if the dependency on the versioned provides is satisfied, this does not prevent another flavour of LAPACK (not satisfying the dependency) to be installed and selected through the alternatives system. I think those alternatives names would need to be per ABI version (of the virtual package) anyhow. So indeed the only clean way of solving this issue seems to forbid coinstallability of several BLAS or LAPACK flavours. But the latter is considered as a feature, not as a bug. I agree that using the alternatives system for a shared library is a bit ugly and does not play well with our tooling, but that’s a choice that was made long ago and it also brings some flexibility for the user (it’s easy to switch from one implementation to the other). Is ease of switching the only reason for using the alternatives system here? Maybe we should rethink this decision as it really does not play well with our tooling and you could just as well use apt to switch the implementation. Cheers Jochen signature.asc Description: PGP signature
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Le vendredi 16 décembre 2022 à 13:47 +0100, Jochen Sprickerhof a
écrit :
> Hi Sébastien,
>
> * Sébastien Villemot [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)
>
> So only one lib can be installed at the same time and drop the
> alternatives system.
In the current system, in which the BLAS and LAPACK implementation are
decided through the alternatives system, it’s not possible to solve the
problem through versioned provides. Because even if the dependency on
the versioned provides is satisfied, this does not prevent another
flavour of LAPACK (not satisfying the dependency) to be installed and
selected through the alternatives system.
So indeed the only clean way of solving this issue seems to forbid
coinstallability of several BLAS or LAPACK flavours. But the latter is
considered as a feature, not as a bug. I agree that using the
alternatives system for a shared library is a bit ugly and does not
play well with our tooling, but that’s a choice that was made long ago
and it also brings some flexibility for the user (it’s easy to switch
from one implementation to the other).
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Hi Sébastien,
* Sébastien Villemot [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)
So only one lib can be installed at the same time and drop the
alternatives system.
Cheers Jochen
signature.asc
Description: PGP signature
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Hi Paul,
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 hope this clarifies.
Best,
¹ See https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
signature.asc
Description: This is a digitally signed message part
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Hi Sébastien, 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? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Control: block -1 by 1025699 Le mardi 13 décembre 2022 à 21:50 +0100, Paul Gevers a écrit : > Source: lapack, openturns > Control: found -1 lapack/3.11.0-2 > Control: found -1 openturns/1.20-5 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > With a recent upload of lapack the autopkgtest of openturns fails in > testing when that autopkgtest is run with the binary packages of lapack > from unstable. It passes when run with only packages from testing. In > tabular form: > > passfail > lapack from testing3.11.0-2 > openturns from testing1.20-5 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of lapack to testing > [1]. Due to the nature of this issue, I filed this bug report against > both packages. Can you please investigate the situation and reassign the > bug to the right package? Thanks Paul. 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. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1026055: lapack breaks openturns autopkgtest: undefined reference to `ztrsyl3_' (and 3 more)
Source: lapack, openturns Control: found -1 lapack/3.11.0-2 Control: found -1 openturns/1.20-5 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of lapack the autopkgtest of openturns fails in testing when that autopkgtest is run with the binary packages of lapack from unstable. It passes when run with only packages from testing. In tabular form: passfail lapack from testing3.11.0-2 openturns from testing1.20-5 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of lapack to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=lapack https://ci.debian.net/data/autopkgtest/testing/amd64/o/openturns/29301955/log.gz /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `ztrsyl3_' /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `ctrsyl3_' /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `dtrsyl3_' /usr/bin/ld: /lib/x86_64-linux-gnu/liblapacke.so.3: undefined reference to `strsyl3_' collect2: error: ld returned 1 exit status autopkgtest [01:16:06]: test cxx-Ceres-test OpenPGP_signature Description: OpenPGP digital signature
