Re: New segfault with flexiblas/openblaso
I found that this may be a packaging issue in openblas. What I did was
to download the source distribution, then
$ tar xf openblas-0.3.10.tar.gz
$ cd OpenBLAS-0.3.10
$ make USE_THREAD=1 USE_OPENMP=1
$ CMD='octave -H -q --no-window-system --no-site-file --eval
pkg("load","statistics");test("/usr/share/octave/pac
kages/statistics-1.4.1/canoncorr.m");'
$ FLEXIBLAS=$PWD/libopenblas.so $CMD
PASSES 7 out of 7 tests
My guess is that the spec requires a "make clean" between builds with
different flags. Makes sense?
Iñaki
On Fri, 4 Sep 2020 at 11:22, Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
On Fri, 4 Sep 2020 at 11:16, Susi Lehtola
<jussilehtola(a)fedoraproject.org> wrote:
>
> On Fri, 4 Sep 2020 10:57:13 +0200
> Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
> > Hi,
> >
> > Strange... Let me bring this upstream to see whether this is
> > flexiblas' or openblas' fault. In the meanwhile, exporting
> > FLEXIBLAS=netlib before the tests makes use of the reference
> > implementation, so everything should be slower but safer. And if this
> > starts happening in the wild, we can change to openblas-serial with a
> > quick update of FlexiBLAS.
>
> ... which would lead to a horrendous regression in performance, utterly
> ruining parallellization.
>
> If this happens, there is no alternative but to resort to the
> contingency plan of the FlexiBLAS as BLAS/LAPACK manager: undo all
> changes and rebuild all packages so that they work again as intended.
If this is a bug in FlexiBLAS, by experience I'm sure it will be fixed
soon. If not, then it's a bug in openblaso, which should be also
tracked down and fixed; otherwise, would you link packages back to
openblaso knowing it's faulty?
--
Iñaki Úcar
--
Iñaki Úcar