<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Colin,<div><br></div><div>I also found an article referring to a blog of Dirk: <a href="http://techyoubaji.blogspot.de/2012/12/r-uses-different-blas-and-lapack.html">http://techyoubaji.blogspot.de/2012/12/r-uses-different-blas-and-lapack.html</a></div><div><br></div><div>Maybe it is interesting for you. </div><div><br></div><div><br></div><div>Best</div><div><br></div><div>Simon<br><div><div>On May 31, 2013, at 9:55 PM, Simon Zehnder <<a href="mailto:szehnder@uni-bonn.de">szehnder@uni-bonn.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Isn't this actually an option when installing R (<a href="http://www.cran.r-project.org/doc/manuals/R-admin.html">http://www.cran.r-project.org/doc/manuals/R-admin.html</a>)? If it hasn't been explicitly stated in the configure stage of R via --with-lapack, R uses its internal routines.  <div><br></div><div>Best</div><div><br></div><div>Simon</div><div><br></div><div><div><div>On May 31, 2013, at 9:31 PM, Colin Rundel <<a href="mailto:rundel@gmail.com">rundel@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite">For certain operations R does _not_ go to lapack but uses its own. I can<br>never remember if chol() was one of them -- but this suggests it.  As I<br>mentioned in my earlier email you probably really have to follow the chol()<br>call all the way down (in the sources).<br></blockquote></div><br><div>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.</div><div><br></div><div>To simplify things as much as possible I've remove all blas and lapack packages except for:</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>libblas3</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>libblas-dev</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>liblapack3</div><div><span class="Apple-tab-span" style="white-space:pre">   </span>liblapack-dev</div> <div>Looking at the shared library dependencies of the binary created by sourceCpp I get:</div><div><br></div><div><div>> system("ldd /tmp/RtmpTjd5Oq/sourcecpp_7912704276cb/sourceCpp_51716.so")</div><div>        linux-vdso.so.1 =>  (0x00007fff72cb6000)</div><div>        liblapack.so => /usr/lib/R/lib/liblapack.so (0x00007fc726530000)</div><div>        libRcpp.so => /home/rundel/R/library/Rcpp/lib/libRcpp.so (0x00007fc7262b4000)</div><div>        libR.so => /usr/lib/R/lib/libR.so (0x00007fc725db1000)</div><div>        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc725aae000)</div><div>        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc725874000)</div><div>        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7254ab000)</div><div>        libguide.so => /usr/lib/R/lib/libguide.so (0x00007fc725338000)</div><div>        /lib64/ld-linux-x86-64.so.2 (0x00007fc728374000)</div><div>        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc725033000)</div><div>        libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fc724d92000)</div><div>        libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007fc724b50000)</div><div>        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fc724911000)</div><div>        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fc7246ee000)</div><div>        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fc7244de000)</div><div>        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc7242c7000)</div><div>        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc7240be000)</div><div>        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc723eba000)</div><div>        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fc723cab000)</div><div>        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc723a8d000)</div><div>        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fc723865000)</div></div><div><br></div><div>I have also created a standalone armadillo implementation (<a href="https://gist.github.com/rundel/5687320">https://gist.github.com/rundel/5687320</a>) which works correctly and results in the following shared library dependencies:</div><div><br></div><div><div>$ ldd chol_test</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>linux-vdso.so.1 =>  (0x00007fff6c9fe000)</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f8f10088000)</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8f0fd85000)</div><div><span class="Apple-tab-span" style="white-space:pre">   </span>libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8f0fb6e000)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8f0f7a6000)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f8f0f506000)</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f8f0f1f1000)</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8f0eeec000)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/lib64/ld-linux-x86-64.so.2 (0x00007f8f10da7000)</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f8f0ecb7000)</div></div><div><br></div><div>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.</div><div><br></div><div>-Colin</div><div><br></div><div><br></div><div><br></div></div>_______________________________________________<br>Rcpp-devel mailing list<br><a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-project.org</a><br><a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a></blockquote></div><br></div></div>_______________________________________________<br>Rcpp-devel mailing list<br><a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-project.org</a><br>https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</blockquote></div><br></div></body></html>