similar to: R with external BLAS fails regression test

Followup: I have checked my package nleqslv which uses dgemv only from Fortran, on Kubuntu 18.04 with the development version of R. No errors or problems. Berend > On 12 Sep 2019, at 08:57, Berend Hasselman <bhh at xs4all.nl> wrote: > > > I have tried what I proposed in a virtual Kubuntu 18.04 which uses gfortran 7.4. > I used the latest development version of R. >

Berend, I do not think this works with gfortran 7+. I am calling the BLAS subroutine dgemv from Fortran code in my package eha, and the check (with R-devel) gives: gmlfun.f:223:1: warning: type of ?dgemv? does not match original declaration [-Wlto-type-mismatch] & score, ione) ^ /home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type mismatch in parameter 12

On 2019-09-11 22:16, Avraham Adler wrote: > Can you write a small C function that calls LAPACK call that fro your > Fortran code? Yes, an extra step but maybe less traumatic than rewriting > parts of LAPACK directly. Yes, I know how to do that, but I find it somewhat bizarre that it is impossible to call a Fortran subroutine from Fortran. And rewriting 'dgemv' was simple:

Dear list, What is the recommended incantation on Fedora 32 to swap out the openblas BLAS that the packaged (rpm) version of R-core installs for ATLAS? I'm running into some problems with some big models I want to fit using the mgcv package, and openblas is apparently not thread safe and is causing problems. I have the following installed: $ dnf list installed | grep ^R R-core.x86_64

Of course, even a simpler trick is to launch R as follows: LD_PRELOAD=/lib64/atlas/libsatlas.so.3 R and then the symbols in libsatlas take precedence over libopenblas. Or a mix between both alternatives, i.e., setting LD_PRELOAD=/path/to/some/link R and then change that link to point to openblas, atlas... Whatever suits you best. I?aki On Wed, 27 May 2020 at 11:00, I?aki Ucar <iucar at

On Wed, 27 May 2020 at 21:40, Gavin Simpson <ucfagls at gmail.com> wrote: > > Thanks I?aki, that is exactly what i was looking for, esp the last > option which I have now configured as an alias for easy remembering. > > I can answer the question re USE_LOCKING=1. I think that using both > those options is required to get thread-safety even if openblas was > compiled for

Sorry for cross-posting, but I realized my question might be more appropriate for r-devel... Thank you, Giovanni ________________________________________ From: R-help <r-help-bounces at r-project.org> on behalf of Giovanni Petris <gpetris at uark.edu> Sent: Tuesday, September 10, 2019 16:44 To: r-help at r-project.org Subject: [R] Calling a LAPACK subroutine from R Hello R-helpers!

On Wed, 27 May 2020 at 23:03, Gavin Simpson <ucfagls at gmail.com> wrote: > > Thanks (again) I?aki. > > There was a typo in my reply above. I should have said: I *can't* > answer the question re USE_LOCKING=1. :) > Those other suggestions are really helpful too; I really didn't > understand what the difference was (I'm still not clear what the >

Hi guys, interestingly, my problem seems to be solved by writing a FORTRAN wrapper for the Fortran code! (As long as the check doesn't get smarter...). This is the relevant part of my Fortran code: ----------------------------------------------------------- subroutine gmlfun(what, & totevent, totrs, ns, & antrs, antevents, size, & totsize,

I'm setting up an Ubuntu?virtual machine?that will use 4-Intel Xeon CPU x5650.? I'd like to compile R with a BLAS but the question is whcih one.? Seems like the only free ones are GotoBLAS which I'm not sure is being maintained for newer CPUs and OpenBLAS for Loongson CPUs.? I saw a favorable report on OpenBLAS

Hello, I am in the process of writing an R extension for parallelized MCMC, with heavy use of compiled code (C++). I have been getting my feet wet by implementing a simple matrix-vector multiplication function in C++ (which calls a BLAS level 2 function dgemv), and comparing it to the '%*%' operator in R (which apparently calls a BLAS level 3 function dgemm). Interestingly, I cannot

Thanks I?aki, that is exactly what i was looking for, esp the last option which I have now configured as an alias for easy remembering. I can answer the question re USE_LOCKING=1. I think that using both those options is required to get thread-safety even if openblas was compiled for single thread use. I don't know to what extent Simon has engaged with upstream on this etc. All I know is

Thanks (again) I?aki. There was a typo in my reply above. I should have said: I *can't* answer the question re USE_LOCKING=1. Those other suggestions are really helpful too; I really didn't understand what the difference was (I'm still not clear what the differences are between say openblas-openmp and openblas-openmp64), but I did get R to pass mgcv's thread safe test with both

Dear All, I am building R from source[1], following what is done in "rules" for building Debian's R. But the R I generate, in contrast to the standard Debian's R, will not change the BLAS and LAPACK libraries it uses when I change them via "update-alternatives". I have no idea what I am doing wrong (but, somehow, I've been quite capable of making the same

I have tried what I proposed in a virtual Kubuntu 18.04 which uses gfortran 7.4. I used the latest development version of R. It worked just as on macOS. Berend > On 11 Sep 2019, at 22:07, G?ran Brostr?m <goran.brostrom at umu.se> wrote: > > Berend, > > I do not think this works with gfortran 7+. I am calling the BLAS subroutine dgemv from Fortran code in my package eha,

Can you write a small C function that calls LAPACK call that fro your Fortran code? Yes, an extra step but maybe less traumatic than rewriting parts of LAPACK directly. Avi On Wed, Sep 11, 2019 at 4:08 PM G?ran Brostr?m <goran.brostrom at umu.se> wrote: > Berend, > > I do not think this works with gfortran 7+. I am calling the BLAS > subroutine dgemv from Fortran code in my

Hi R usrs, I want to build R-2.10.0 on HP-UX, but I got following error message: ld: Unsatisfied symbol "zgemm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "zgemv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "zherk" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "ztrsm" in file

Hi Gavin, On Wed, 27 May 2020 at 01:15, Gavin Simpson <ucfagls at gmail.com> wrote: > > Dear list, > > What is the recommended incantation on Fedora 32 to swap out the > openblas BLAS that the packaged (rpm) version of R-core installs for > ATLAS? I'm afraid there is no official mechanism in place to do that yet. There was a proposal [1], but it was never pushed

Thanks Keith. We checked, and indeed libopenblas is not linked against libomp nor libgomp. We suspect this is because we used conda to install R and OpenBLAS. So I guess we should be barking up the conda tree instead? By the way, I also noticed on my home machine (Ubuntu), /usr/lib/libopenblas.so.0 is also not linked against those, for what that's worth. Regards, Ben On 01/10/2018 12:04

Executive summary: I believe revision 86265 makes it more difficult to build R with OpenBLAS on Windows as now the entire LAPACK needs to be built to obtain zspmv. Is there anything that can be done to allow the former behavior to be used, something in Mkrules.local perhaps? Detailed Explanation: I have been building R with OpenBLAS for Windows 64 for over a decade by patching