[R-sig-Debian] GotoBLAS2 breaks lapack

[Dirk Eddelbuettel]

On 25 February 2011 at 21:47, dks wrote:
| I'm relatively new to R on Ubuntu (moving from Windows), and I'm trying to
| get GotoBLAS2 working.  I installed (from a CRAN mirror) the pre-built
| binaries of R (which, as far as I know, is compiled as a shared library) on
| Ubuntu 10.10 using
| apt-get install r-base r-base-dev

Good.
 
| I successfully built GotoBLAS2 from source, copied the library to /usr/lib
| and created s symbolic link from libblas.so.3gf to point to the new
| GotoBLAS2 library.

You did that wrong.  This isn't easy stuff (as understanding how the plug &
play of all the BLAS / LAPACK alternatives is implemented is non-trivial),
but forcing it isn't the right approach.  Below you mention my gcbd
paper/package. In it, I use a rather awesome 'gotoblas2-helper' package which
_automates_ creating a deb from the gotoblas2 sources.

I suspect your problem comes from the fact that you only took half of what
GotoBlas can give.  If I look at the deb created from the helper:

edd at max:~/atlas$ dpkg -c /var/spool/gotoblas2-helper/archive/gotoblas2_1.13-1_amd64.deb |grep lib
drwxr-xr-x root/root         0 2010-07-05 18:57 ./usr/lib/
drwxr-xr-x root/root         0 2010-07-05 19:00 ./usr/lib/gotoblas2/
-rw-r--r-- root/root  10445138 2010-07-05 19:00 ./usr/lib/gotoblas2/libblas.a
-rw-r--r-- root/root   8672978 2010-07-05 19:00 ./usr/lib/gotoblas2/liblapack.a
-rw-r--r-- root/root   5491025 2010-07-05 19:00 ./usr/lib/gotoblas2/libblas.so.3gf.0
-rw-r--r-- root/root   7427273 2010-07-05 19:00 ./usr/lib/gotoblas2/liblapack.so.3gf.0
edd at max:~/atlas$ 

you see that I got libblas.so and liblapack.so.

So your crashes / lack of lapack success may well be due to Goto assuming its
own lapack, but not getting it.

Dirk

 
| I think the symbolic links and everything are set up correctly, because the
| BLAS itself works: I'm using Dirk Eddelbuettel's gbcd package to benchmark
| the difference, and I can still run the matrix multiplication benchmarks (I
| guess crossprod doesn't depend on lapack?), and I'm getting a 15x speedup
| over the default BLAS with 8 cores used.  The problem, though, is that when
| I try to run anything that depends on lapack--like qr()--I get the
| following:
| 
| Error in qr.default(a, LAPACK = TRUE) : lapack routines cannot be loaded
| In addition: Warning message:
| In qr.default(a, LAPACK = TRUE) :
|   unable to load shared object '/usr/lib64/R/modules//lapack.so':
|   /usr/lib/liblapack.so.3gf: undefined symbol: ATL_chemv
| 
| If I delete the symbolic link to GotoBLAS2 and stick the default BLAS back
| in there, everything works fine, and it finds lapack once again.  I guess I
| don't understand the relationship between BLAS and lapack well enough to
| figure out what's happening, because I don't understand how replacing the
| BLAS breaks lapack, and yet the new BLAS still works!  Nothing I've found
| online suggests that I need to rebuild lapack to go with GotoBLAS2--I
| thought that it should just use the system-wide version.
| 
| I've read everything in the R-sig-Debian archives on this, and the
| suggestion always seems to be to use the precompiled binaries rather than
| building R locally, but I've already done that.
| 
| Any help would be much appreciated.
| 
| Thanks,
| Dan
| 
| 	[[alternative HTML version deleted]]
| 
| _______________________________________________
| R-SIG-Debian mailing list
| R-SIG-Debian at r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com