Bug#732064: lapack depends on specific blas implementation

[Andrey Gursky]

2013/12/13, Sébastien Villemot <sebastien at debian.org>:
> Le vendredi 13 décembre 2013 à 14:34 +0100, Andrey Gursky a écrit :
>
>> after updating lapack from 3.4.2 to 3.5.0, provided instead of atlas
>> openblas is selected, running a program, using lapack results in
>> following error:
>>
>> symbol lookup error: /usr/lib/liblapack.so.3: undefined symbol:
>> ATL_dGetNB
>
> Your problem looks very much like #576972 and its many duplicates. I.e.
> it looks like you are using ATLAS for the LAPACK alternative and
> reference BLAS or OpenBLAS for the BLAS alternative.
>
> To confirm this, can you please give the output of the following two
> commands:
>
>  update-alternatives --display libblas.so.3
>  update-alternatives --display liblapack.so.3
>

Sebastien, thanks for pointing this out. I've also got caught in the
same trap. But this would mean a trade-off, since openblas's version
of lapack is just striped away for now. Should I open a new bug for
openblas or could it be, that optimizations of openblas's lapack are
not significant enough?

I'm wondering, whether lapack interface could be remaining general
modified in a way, atlas and openblas could use it without changing.
Or the things are more complicated?

Thanks,
Andrey