[SRU] openblas: -Wl,-Bsymbolic-functions should be stripped from LDFLAGS
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
hypre (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Focal |
Invalid
|
Undecided
|
Unassigned | ||
openblas (Debian) |
Fix Released
|
Unknown
|
|||
openblas (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Graham Inggs |
Bug Description
[Impact]
Users of GNU R and GNU Octave in Ubuntu 20.04 found that certain operations hang, never returning results.
[Test Case]
apt install r-base-core
Rscript -e "example(solve)"
apt install libopenblas-dev
Rscript -e "example(solve)"
Executing Rscript the first time should return results almost instantly.
Installing libopenblas-dev ensures that libopenblas0-
If the bug is present, running Rscript the second time will hang.
Another test case, using Octave, can be found in #1870138
[Regression Potential]
This fix is already present in lapack for some time, see Debian bug #722252
In case of regression, users should be able to switch to alternate blas variants.
.
It may be possible that in fixing libopenblas0-
We should watch out for test timeouts or incorrect results.
Hopefully the autopkgtests will catch any of that.
-------
openblas >= 0.3.7+ds-3 causes an autopkgtest regression in hypre on armhf on Ubuntu infrastructure.
There was a major restructuring of the openblas packaging in Debian version 0.3.7+ds-2 uploaded to experimental.
http://
Running tests
running TEST_ams ... autopkgtest [17:08:06]: ERROR: timed out on command
I have tried to reproduce this error on a Debian porterbox (armhf chroot on arm64 kernel) and on a Raspberry Pi 3 (armhf focal-proposed chroot on focal arm64 kernel). The autopkgtests using binaries from the archive are successful, and rebuilding the packages locally is fine too.
While investigating, I found the same tests are run while building the hypre package.
I uploaded the hypre package to my PPA with the following change:
--- a/debian/control
+++ b/debian/control
@@ -10,8 +10,8 @@
debhelper-compat (= 12),
pkg-config,
gfortran,
- libblas-dev | libopenblas-dev | libatlas-base-dev | libblas.so,
- liblapack-dev | libopenblas-dev | libatlas-base-dev | liblapack.so,
+ libopenblas-dev | libblas-dev | libatlas-base-dev | libblas.so,
+ libopenblas-dev | liblapack-dev | libatlas-base-dev | liblapack.so,
libsuperlu-dev, libsuperlu-
libltdl-dev,
libtool,
i.e. building the package with libopenblas-dev instead of libblas-dev and liblapack-dev.
https:/
The builds across all architectures seemed to fail in the same way as the autopkgtests on armhf.
TEST_ams would start, and eventually the build would time out.
see e.g. the build log for amd64:
Again, I was unable to reproduce this error locally on amd64 or armhf.
This regression prevents openblas, yade, eckit, sdpa, openmolcas and bolt-lmm from migrating from -proposed.
tags: | added: update-excuse |
summary: |
- openblas: cause autopkgtest failure in hypre armhf + openblas: causes autopkgtest failure in hypre armhf |
tags: | added: id-5e29cc4b6b85874329c04089 |
summary: |
- openblas: causes autopkgtest failure in hypre armhf + openblas: -Wl,-Bsymbolic-functions should be stripped from LDFLAGS |
Changed in hypre (Ubuntu): | |
status: | New → Invalid |
Changed in hypre (Ubuntu Focal): | |
status: | New → Invalid |
description: | updated |
summary: |
- openblas: -Wl,-Bsymbolic-functions should be stripped from LDFLAGS + [SRU] openblas: -Wl,-Bsymbolic-functions should be stripped from LDFLAGS |
Changed in openblas (Ubuntu Focal): | |
status: | Confirmed → In Progress |
assignee: | nobody → Graham Inggs (ginggs) |
Changed in openblas (Debian): | |
status: | Unknown → Fix Committed |
description: | updated |
tags: |
added: verification-done verification-done-focal removed: verification-needed verification-needed-focal |
Changed in openblas (Debian): | |
status: | Fix Committed → Fix Released |
I would like someone to investigate this further: if this is a real issue and how users can be affected. Since this looks like a regression in openblas. I built the same package that Graham prepared on a PPA with only Updates enabled and it built fine - so it's proof that the openblas in -proposed does something really fishy.
On one hand it feels like something we might hint, but first I'd like to know if this is something we only see on builders/Ubuntu-ADT and why that is happening. Julian is investigating this further.