similar to: R and Fortran 9x -- advice

We have a user here who is attempting to compile a package which requires f90 (gfortran will do). Our version of R was built with f77 (g77). When the user attempts to build the package, f77 is always invoked and fails due to the presence of f90 features. Is there a simple method or some documentation on how to force a package build to use a different compiler than the one used in

I have been revising some FORTRAN 77 routines in R packages I have previously submitted. Since R is now using gfortan I experimented with some Fortran 90 code (array intrinsics primarily). So far the code is still in F77 fixed format, in files suffixed .f (not .f90), but incorporates some F90 constructs. It has worked fine in linux/R. I tried to follow the thread of previous discussions

Hi all, (Originally posted to r-help) I'm porting a package that I've worked on for OS X to Windows. The package is written in F95 so I need to compile it with gfortran and link it with gcc4. I've been trying to build an R with gcc4 without luck so far. If there is a binary of such a thing info would be appreciated. This package requires a Makefile. My question is, how can I find

Is it possible to run Fortran 95 code from R? I don't think so, but hopefully someone can prove me wrong. Here is the test I tried: A little fortran 95 subroutine: subroutine allloc() real, dimension(:, :), allocatable :: a integer :: n n = 10 allocate(a(n,n+1)) end I then compiled: >g95 -c allloc.f >R CMD SHLIB allloc.o Here is what happens when I try to dyn.load it in R 2.1.0

Is it possible to run Fortran 95 code from R? I don't think so, but hopefully someone can prove me wrong. Here is the test I tried: A little fortran 95 subroutine: subroutine allloc() real, dimension(:, :), allocatable :: a integer :: n n = 10 allocate(a(n,n+1)) end I then compiled: >g95 -c allloc.f >R CMD SHLIB allloc.o Here is what happens when I try to dyn.load it in R 2.1.0

Hi, all, We just got the Sun Performance Library for our Suns running Solaris 2.6, and I read the relevant section of the "R Installation and Administration Manual" about configuring R to use BLAS. The manual suggests you must use Sun's "cc" and "f95" (maybe "f90"?) compilers in order to use the Performance Library. We have "cc" but not

Hi, All, I have come across a problem building a DLL from .f90 source (R 2.3.1, Windows XP). When using the R CMD SHLIB procedure, the DLL itself was being built, but its export table was empty. Among the output from R CMD SHLIB the following message appeared: c:\mingw\bin\nm.exe: 'a.out': No such file The reason is the empty list of dependencies in the pattern rule for DLLs

I too have some messy F77 code that I'm considering porting to F90. BUT: Has anyone had luck creating shared-objects from F90 to load in R? What about submitting packages to CRAN with F90 code? BTW: I'm using the Intel compilers for Linux - free for Not-for-profit orgs. -R -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read

Dear list members, In re-running with GLMM() from the lme4 package a generalized-linear mixed model that I had previously fit with glmmPQL() from MASS, I'm getting a warning of a convergence failure, even when I set the method argument of GLMM() to "PQL": > bang.mod.1 <- glmmPQL(contraception ~ as.factor(children) + cage + urban, + random=~as.factor(children) + cage +

On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: >> ps We do have one oddity left in llvm-gfortran from current llvm >> svn. I find everytime I compile something with llvm-gfortran that >> I get a series of warning messages... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/

We have (spatial statistics) group here that are (about to) interface Fortran 90 and/or 95 software to R and/or S-plus. My recommendation has been against this because of non-availability of GNU or other free (not only moneywise, in the GNU sense) compilers for Fortran 9x. Does anybody have good guesses about the future here? The user group here say they like F 9[05] because of its ``object

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

Hi all, I'm preparing a package which uses .Fortran to interface a Fortran 95 function. This F95 function simply receives the name of a file from R, opens this file and forwards its content to a F95 module, which, in turn, makes the real computation. The F95 module is a pre-existing one and I'm trying to use it in its actual state. Thus, data transfer between R and this F95 module is

I am reading the manual sections illustrating how to call a Fortran subroutine from R. I feel uneasy at the explicit statement about ".Fortran" interface working with Fortran 77. I would like to call a Fortran-90 subroutine from my R script. Is that supported at all ? Thank you, Maura tutti i telefonini TIM! [[alternative HTML version deleted]]

I have gotten this error while attempting to build R-2.13.2 and R-2.14.0 using ./configure --with-x=no --enable-R-shlib, and ./configure --with-x=no Red Hat Enterprise Linux Server release 5.6 (Tikanga) ========================= Warning in solve.default(rgb) : unable to load shared object '/users/home/mked/R-2.13.2/modules//lapack.so': /users/home/mked/R-2.13.2/lib/libRlapack.so:

Hello, I work under windows xp and I am trying to build a R package with a subroutine written in fortran 90. I have installed all the updated tools and I am working with R-2.4.0 or R-2.5.0. When I check a package with a subroutine in fortran 77 (and extension f) everything is ok. When I try to build the same package with a subroutine in fortran 90 (with extension f90) the following warning

I am building from source on RHEL 4 and have run into a problem while running "make check": running code in 'lapack.R' ...make[3]: *** [lapack.Rout] Error 1 make[3]: Leaving directory `/opt/R/R-2.9.1/tests' make[2]: *** [test-Specific] Error 2 make[2]: Leaving directory `/opt/R/R-2.9.1/tests' make[1]: *** [test-all-basics] Error 1 make[1]: Leaving

Has anyone achieved a current successful build of R 1.8 or 1.9 or earlier for HPUX Tru 64 OSF 5.1? There is no binary version of R for HPUX Tru 64 OSF 5.1. The R admin manual mentions that the native make fails on "Alpha/OSF (aka Tru 64)" and gnu make must be used instead. There are problems reported with building R versions around 1.4 from 2002 on R-devel, some of which were fixed with

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

Hi, To make a calculation (an innermost loop) that uses optimize faster, I think I should write things in C. Is it possible to call fmin, which is called by optimize, from C? It is not listed in Writing R extensions, but I found double Brent_fmin(double ax, double bx, double (*f)(double, void *), void *info, double tol); in Applic.h. Is this the function I am looking for?