On 06/16/2014 10:16 AM, Martyn Plummer wrote:
On Mon, 2014-06-16 at 09:50 -0400, Tom Callaway wrote:
On 06/16/2014 09:38 AM, Martyn Plummer wrote:
Something like the previous behaviour could be put in place by adding the option --enable-BLAS-shlib when R is configured. Then libRblas.so will be built as before. However, this libRblas will not contain a copy of the reference blas that comes with R. Instead it will be just be a stub that redirects BLAS calls to the external BLAS library. (NB You must also use --enable-R-shlib for this to work, but this is the case for the Fedora SRPM so not a problem). This option gives you the best of both worlds. However, such a change would have to wait until the next major release of R.
I think we'd enable such a change if it were supported in R.
Sorry I'm not being clear. This option already exists. I just tested it. But if you push an update of the R 3.1.0 RPM you might break R packages that need blas and which are already installed by users. This also applies to future R 3.1.1 since it will use the same personal package library (e.g. ~/R/x86_64-redhat-linux-gnu-library/3.1) . Hence my suggestion to wait for the next major release of R to make the change. However, I might be wrong about that. You certainly can't get rid of libRblas if it exists, but you might be able to add a stub libRblas without affecting packages that are already installed.
Revisiting this, this seems to work for libRblas, but _not_ for libRlapack. When we pass: --with-lapack --with-blas --enable-BLAS-shlib It results in a libRlapack.so that is not a shim, but rather, built from the bundled sources... which is not what we want in Fedora. Thoughts? ~tom == ?.???`?.??`?.??.???`?.?><(((?> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal -------------- next part -------------- A non-text attachment was scrubbed... Name: tcallawa.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: <https://stat.ethz.ch/pipermail/r-sig-fedora/attachments/20140710/c8029cc1/attachment.vcf>