similar to: help compiling package with g77

OK: despite Dirk's very kind help, I decided that trying to deal with R configuration and Debian configuration simultaneously was too difficult. I did manage to solve my problem by reconfiguring/making/ installing all of 2.3.1 from source: ./configure F77=/usr/bin/g77 make make install A few questions inspired by this experience: (1) it seems a bit odd that R sets F77=gfortran by

> rab45+ at pitt.edu wrote: >> Jerry, >> >> Here are the two R packages. >> >> Thanks. >> >> Rick > All the fortran codes compile OK so the problem is invoking the compiler > you > want. One approach which is a work around is to rename the gfortran > executable > to somthing else like gfortran-save and create a link called gfortran that

Hi all, Thanks to all who offered advice on using F95 in R. Now I'm trying to compile a test package using gfortran, Linux 2.4.21 and R 2.1.0. I was able to successfully compile and use a test F95 routine by setting my environment variables as follows in bash: export PATH=~/bin/:$PATH export F77=gfortran export LD_LIBRARY_PATH=~/bin/irun/lib export GFORTRAN_STDIN_UNIT=-1 Now I'm

Hi I've got two builds of R, one using g77 (version 3.4.6) and the other using gfortran (version 4.1.2). The two builds are otherwise identical as far as I can tell. The one which used g77 performs crossprod()s roughly twice as fast as the gfortran one. I'm wondering if this rings a bell with anyone, and if so, are you aware of any configure settings which will improve the performance

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:

Building the prerelease of llvm-gcc 2.4 on Intel darwin9 with the following patch... --- llvm-gcc-4.2-2.3.999-20081024.source/gcc/stub-c.c.org 2008-10-30 18:55:45.000000000 -0400 +++ llvm-gcc-4.2-2.3.999-20081024.source/gcc/stub-c.c 2008-10-30 18:57:29.000000000 -0400 @@ -157,3 +157,27 @@ { gcc_assert(0); } + + +bool cvt_utf8_utf16 (const unsigned char *, size_t, unsigned char **, +

Hello, I am trying to compile some F77 subroutines as shared objects for R on my Mac. --> Mac OS-X Version 10.4.11 (Tiger Intel Mac) I have done this (successfully) before on Sun Solaris and Linux Fedora systems using the following command. > R CMD SHLIB myfile.f I have g77 installed from this page. http://hpc.sourceforge.net/ I am using R 2.8.1, and I have installed all 4 additional

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

From the configure output of the latest devel snapshot: > checking for g77... no > checking for f77... no > checking for xlf... no > checking for frt... no > checking for pgf77... no > checking for fl32... no > checking for af77... no > checking for fort77... no > checking for f90... no > checking for xlf90... no > checking for pgf90... no > checking for

Hi, everyone. This may be properly a fortran question rather than an R question. I'm trying to add a few print statements to otherwise working fortran code in one of the libraries so I can see what's going on in the code. I have no problem doing so on an SGI machine, but under LinuxPPC I've run into a problem. The code compiles and creates a shared object (.so), but when I issue

The current llvm/llvm-gcc4.2 svn is now fixed with respect to the extra warnings that were being emitted by the gfortran compiler. The gfortran testsuite results under Intel Darwin9 are appended below. Jack Native configuration is i686-apple-darwin9 === gfortran tests === Running target unix/-m32 FAIL: gfortran.dg/aint_anint_1.f90 -O (internal compiler error) FAIL:

Hi there, I realize that this is a bit of a strange question, but here goes. In SAS, one can use the REG procedure to carry out a least-squares regression analysis. By specifying the R-SQUARE option in the SELECTION command, the program carries out regressions for every combination of every independant variable against the dependant variable. This is useful in smaller datasets, though difficult

Full_Name: Sigbert Klinke Version: 2.1.1 OS: Suse Linux 10.0 (Full DVD) Submission from: (NULL) (141.20.100.252) Suse 10.0 installs only a Fortran 95 compiler with g77 compability mode. Using this leads in "configure" to an abortion with problems about "FPICFLAGS". Deinstalling g77 compatiblity mode, using f2c, compiles R. But after calling R() the program shows its entrance

Using the proposed patch for enabling the i386 multilib under the x86_64-apple-darwin build... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025040.html the following gfortran testsuite results are obtained... Native configuration is x86_64-apple-darwin10 === gfortran tests === Running target unix/-m32 FAIL: gfortran.dg/aint_anint_1.f90 -O (internal compiler error) FAIL:

Building llvm 2.3 and llvm-gcc4.2-2.3 on Mac OS X 10.5, I am seeing the following failures remaining in the gcc 4.2.1 gfortran testsuite... LAST_UPDATED: Native configuration is i686-apple-darwin9 === gfortran tests === Running target unix FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 execution test FAIL: gfortran.dg/actual_array_constructor_1.f90 -O2 execution test FAIL:

Just for the fun of it (actually in order to test some Fortran more extensively), I've compiled and installed g77, yesterday on our Solaris 2.5.1 machines. After doing (in R's toplevel directory) make distclean ./configure now chooses g77 (instead of Sun's f77 which was chosen before). I now do make make check cd tests/Examples and carefully compare base-Ex.Rout to an

Hello, I use Gentoo and I can't get R 2.0.1 to compile. I used the portage system, Gentoo's source package sytem, and after it uncompresses the source to R, it says that I don't have a fortran compiler. It told me to use f77 flag and re-emerge gcc, which I did with the f77 and fortran flags, but it still won't compile. Does anyone have any ideas? I suspect that gcc has changed

Hello, I am trying to build the R-2.11.1 software for university faculty to use in research projects on a DEC/Compaq/HP AlphaServer model GS160 16CPU/64GB memory running Tru64Unix aka OSF1 version 5.1B-5. Is it known whether it is possible to build the R-2.11.1 software on the platform I am using? In my attempts to build the R-2.11.1 software, I first used the native C and Fortran 77/90/95

I am having trouble using Jim Lindsey's libraries because of unresolved symbols. I am currently using R 0.65.0, but had this problem in earlier releases as well. I have a RedHat 6.0 Linux on i386 and use egcs (upgraded to that distributed with rawhide, after first failures with the libraries): egcs-g77-1.1.2-19 egcs-1.1.2-19 Installation of the libraries works but on loading >

Hi This is Gaurav Khanna, from MacResearch.org - a community for scientists that use the Mac and related hardware for research. One service we perform for the community is supply g77 & gfortran compilers for Mac OS X (which are not supplied by Apple). We are interested in the progress made by LLVM and have some quick questions. We'd appreciate any comments you can make. 1) What is the