similar to: R problems with lapack with gfortran

Dear Thomas, thank you for your input. I've debugged one of the packages and I confirm that the breakage is related to passing of strings from C to Fortran. Indeed, BLAS and LAPACK define a large number of subroutines that take one or more explicit single-character strings as arguments. Other than that, BLAS has only one function (xerbla), which takes a string of unspecified length,

>>>>> Dirk Eddelbuettel writes: > On 10 May 2019 at 13:46, Kurt Hornik wrote: > | >>>>> Dirk Eddelbuettel writes: > | > | > On 10 May 2019 at 10:52, Johannes Ranke wrote: > | > | Thanks, that sounds good. But I need some help as I do not know much about > | > | autoconf and Debian packaging: Is it enough to patch configure.ac (r76467) or

Hi all, i am trying to compile a test, calling from C code R Lapack shared libraries. In particular, i am calling simple LAPACK driver dposv for solving linear equation system A*x=B with positive definite A. My code looks like the following in solve.c ========================== #include<stdio.h> #include <R_ext/BLAS.h> #include <R_ext/Lapack.h> int main(){

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

>>>>> Dirk Eddelbuettel writes: > On 10 May 2019 at 10:52, Johannes Ranke wrote: > | Thanks, that sounds good. But I need some help as I do not know much about > | autoconf and Debian packaging: Is it enough to patch configure.ac (r76467) or > | do we need to update configure as well (r76468)? > Again, that would happen in the sources you pick up from me, and per

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. >

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 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:

On Mon, Aug 29, 2005 at 11:48:23AM +0100, Prof Brian Ripley wrote: > On Mon, 29 Aug 2005, G?ran Brostr?m wrote: > >LAPACK/BLAS routines call xerbla "if an input parameter has an > >invalid value" (exact quote from XERBLA at Netlib). Other types of errors > >are not printed (by xerbla), but it is up to the user to check the return > >value of the argument

Full_Name: G?ran Brostr?m Version: R-2.1.1, 2.2.0 OS: Debian unstable Submission from: (NULL) (213.65.9.59) Some BLAS routines call xerbla for error messages, which results in a message like "LAPACK routine DGER gave error code -9". Suggested solution: In void F77_NAME(xerbla)(char *srname, int *info) { /* srname is not null-terminated. It should be 6 characters. */ char

We are trying to install R2.2.1 on a IBM P655 Cluster, SuSE LE 9.1 We are using gcc v 3.3.3 and we are getting this error on make g77 -fPIC -g -O2 -ffloat-store -c dlamc.f -o dlamc.lo g77 -fPIC -g -O2 -c dlapack0.f -o dlapack0.lo g77 -fPIC -g -O2 -c dlapack1.f -o dlapack1.lo g77 -fPIC -g -O2 -c dlapack2.f -o dlapack2.lo g77 -fPIC -g -O2 -c dlapack3.f -o dlapack3.lo g77 -fPIC -g

Hello I'm trying to run a fortran code which use LAPACK subroutines. I think I should use some points shown in the manual 5.5 Creating shared objects but it is too technical for me :-(... Could anyone help me for the procedure to do: -which part of the manual is relevant for this type of question? actually I'm speaking from writing R extensions, should I read R admin? -point 1.2

Ok, moved to R-devel. I tried to build R-2.3.1. Since I intent to distribute this tuned R to all other who have a computer like mine here at work I thought it was best to stay with the latest stable release. About your suggestion, I could'n find xerblas.o file. And I don't know how to edit libf77blas.a. I tried to open it with VIM (http://vim.sf.net/) but there was a lot of strange

Using ATLAS with R is an old topic quite covered in the "R Administration" manual (and by R's "configure" script collection). I still do not easily manage to build R properly on our new AMD Opteron (2-processor). I did work with the current Atlas 3.6.0, configured manually (but "express" version) to build a threaded ATLAS version, and successfully ran Atlas'

dear list, since matrix manipulations is often of interest in statistical computations, i'd like to get a working example of using Lapack for regression. However, i run into an error. My matrix-lapack-example.c file: #include <R_ext/Lapack.h> void reg(const char* trans, const int* m, const int* n, const int* nrhs, double* a, const int* lda, double* b, const int*

On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas K?nig wrote: > > > - figure out Fortran2003 specification for C/Fortran interoperability > > -- this _sounds_ like the right solution, but I don't think many > > understand how to use it and what is implied (in particular, will > > it require making changes to LAPACK itself?) > > That would actually be fairly

I think this is not a R-devel question. Sorry to all if I'm wrong, please let me know. I managed to build R successfully with the default BLAS but when I change the MKRULES to use ATLAS BLAS and set the path to "C:/cygwin/home/Administrador/ATLAS/lib/WinNT_ATHLONSSE2" I got the following error message (I'm posting only the final part, there was a lot of compilation before this):

Hello there I'm writing some c-code to solve a numerically tough problem for me in R. Looking in Lapack.h, i find the following line F77_NAME(dgesvx)(const int* fact, const char* trans, const int* n, and I believe that "fact" should've been char instead of int, i.e. F77_NAME(dgesvx)(const char* fact, const char* trans, const int* n, My reasoning: In the R-source:

Good afternoon. I am trying to compile a version of Rblas.dll based on ATLAS for the Corei7. I had remembered that there was mention of which file to adjust and that "xerbla" needed to be removed from one of the outputs from the last time I tried a few years ago. The most recent version of the R Installation manual does not say anything about this. An older version (2.10 I believe) has

Hi all, I'm stuck in the installation of R. When I run configure, I got the error: configure: error: --with-readline=yes (default) and headers/libs are not available I followed one answer in some post and use this: ./configure --with-prefix=/home/user/R-2.2.1 --with-readline=no It successfully configured but I encountered another problem while make: gcc -shared -L/usr/local/lib64 -o