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@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@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 | [email protected] | http://dirk.eddelbuettel.com
_______________________________________________
Rcpp-devel mailing list
[email protected]
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
