[Rcpp-devel] R & RcppArmadillo decomposition disagreement

[Dirk Eddelbuettel]

Hi Colin,

On 31 May 2013 at 15:31, Colin Rundel wrote:
|     For certain operations R does _not_ go to lapack but uses its own. I can
|     never remember if chol() was one of them -- but this suggests it.  As I
|     mentioned in my earlier email you probably really have to follow the chol()
|     call all the way down (in the sources).
| 
| 
| I've followed both calls to the best of my ability for both R and armadillo and
| I'm fairly confident that both ultimately result in a call to lapack's dpotrf.
| 
| To simplify things as much as possible I've remove all blas and lapack packages
| except for:
| libblas3
| libblas-dev
| liblapack3
| liblapack-dev

Very good.
  
| Looking at the shared library dependencies of the binary created by sourceCpp I
| get:
| 
| > system("ldd /tmp/RtmpTjd5Oq/sourcecpp_7912704276cb/sourceCpp_51716.so")
|         linux-vdso.so.1 =>  (0x00007fff72cb6000)
|         liblapack.so => /usr/lib/R/lib/liblapack.so (0x00007fc726530000)
|         libRcpp.so => /home/rundel/R/library/Rcpp/lib/libRcpp.so
| (0x00007fc7262b4000)
|         libR.so => /usr/lib/R/lib/libR.so (0x00007fc725db1000)
|         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
| (0x00007fc725aae000)
|         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
| (0x00007fc725874000)
|         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7254ab000)
|         libguide.so => /usr/lib/R/lib/libguide.so (0x00007fc725338000)
|         /lib64/ld-linux-x86-64.so.2 (0x00007fc728374000)
|         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc725033000)
|         libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fc724d92000)
|         libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6
| (0x00007fc724b50000)
|         libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fc724911000)
|         liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fc7246ee000)
|         libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
| (0x00007fc7244de000)
|         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc7242c7000)
|         librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc7240be000)
|         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc723eba000)
|         libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1
| (0x00007fc723cab000)
|         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
| (0x00007fc723a8d000)
|         libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
| (0x00007fc723865000)
| 
| I have also created a standalone armadillo implementation (https://
| gist.github.com/rundel/5687320) which works correctly and results in the
| following shared library dependencies:
| 
| $ ldd chol_test
| linux-vdso.so.1 =>  (0x00007fff6c9fe000)
| liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f8f10088000)
| libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8f0fd85000)
| libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8f0fb6e000)
| libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8f0f7a6000)
| libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f8f0f506000)
| libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3
| (0x00007f8f0f1f1000)
| libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8f0eeec000)
| /lib64/ld-linux-x86-64.so.2 (0x00007f8f10da7000)
| libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0
| (0x00007f8f0ecb7000)

Well done too.
 
| The difference appears to be that the sourceCpp binary is linking to R's lapack
| (/usr/lib/R/lib/liblapack.so) and not the system lapack (/usr/lib/
| liblapack.so.3). However, this does not appear to be the case for blas.

Remind again what your R version / distro / ... is.  On my Ubuntu 12.10 box,
I have

edd at max:~$ ldd /usr/lib/R/modules/lapack.so 
	linux-vdso.so.1 =>  (0x00007fff733ff000)
	libR.so => /usr/lib/libR.so (0x00007f022c352000)
	liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f022b676000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f022b379000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f022afba000)
	libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f0229b1f000)
	libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f02298dc000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f022969f000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f022947d000)
	libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f022926c000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0229055000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0228e4d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0228c48000)
	libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f0228a39000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f022881c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f022ca90000)
	libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f0228507000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f02282f1000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f02280c9000)
	libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f0227e92000)
edd at max:~$ 

and its lapack.so "module" does in fact call out the liblapack.so managed by
the distro via update-alternatives. 

This this is from an Ubuntu binary compiled by Michael's toolchain,
distributed via CRAN (or launchpad, need to check, should be the same anyway)
based on the package I upload to Debian.

Dirk

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