2013/12/13, Sébastien Villemot <sebast...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
