Hi Colin, I also found an article referring to a blog of Dirk: http://techyoubaji.blogspot.de/2012/12/r-uses-different-blas-and-lapack.html
Maybe it is interesting for you. Best Simon On May 31, 2013, at 9:55 PM, Simon Zehnder <[email protected]> wrote: > Isn't this actually an option when installing R > (http://www.cran.r-project.org/doc/manuals/R-admin.html)? If it hasn't been > explicitly stated in the configure stage of R via --with-lapack, R uses its > internal routines. > > Best > > Simon > > On May 31, 2013, at 9:31 PM, Colin Rundel <[email protected]> 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 >> >> 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) >> >> 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. >> >> -Colin >> >> >> >> _______________________________________________ >> Rcpp-devel mailing list >> [email protected] >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > _______________________________________________ > Rcpp-devel mailing list > [email protected] > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
_______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
