similar to: crossprod(): g77 versus gfortran

> 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

I have a package with some embedded legacy FORTRAN code (for computing complex Bessel functions, written in 2003 by C. Bond to implement the algorithms of Zhang and Jin 1996). It worked well until recently [despite warnings about deprecated headers "includes at least one deprecated or antiquated header" -- when I tried to fix these the code stopped working, so I left them alone]. Now an

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

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

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 **, +

I recently upgraded to Rtools28 to build a package under Windows. I see that g77 is no longer in Rtools, but it does have gfortran, and it uses version: GNU Fortran (GCC) 4.2.1-sjlj (mingw32-2) I am compiling some old fortran code as part of a larger project. When I do that, I get undefined references: gcc.exe: s_cmp.o: No such file or directory gcc.exe: s_copy.o: No such file or directory

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:

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:

Colleagues, I have a routine in package labdsv that calls a FORTRAN subroutine. Recently, I was informed that it sometimes gives different results on a PC and Mac, and that the PC version is clearly wrong. I tested it on linux (because I don't have a PC), and I get the same (incorrect) behavior as the PC. Simply by inserting debug WRITE statements in the FORTRAN I would get different,

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

I've for a RHEL 4 box on a P570 system. My end user wants to have a 64-bit version of R compiled due to the large amount of memory they require (this image has 16GB allocated to it). I can compile R fine in 32-bit mode, but it can't use more than 2.4GB of RAM before it falls over and dies. Compiling in 64-bit mode for POWER systems "should" be as easy as adding a

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

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

For those interested: I compiled R-1.9.0beta_2004-04-02 with pgf77/gcc/g++ and g77/gcc/g++, both _without_ fast BLAS. Both passed make check-all. Simple crossprod(m) for fairly large `m' shows that the version compiled with pgf77 is about 15% faster: [andy@leo:scratch]% echo "set.seed(1); m <- matrix(runif(5e7), 1e4); gc(); system.time(crossprod(m))" | R-1.9.0-PGI/bin/R

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:

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:

Linux users are used to all compilers using the same linkage conventions (those of pcc) whereas users of other platforms are used to the idea that code from different compilers cannot in general be mixed. This is no longer true for gfortran on AMD64. Given a double complex function like double complex function zdotc(n,zx,incx,zy,incy) gfortran returns the result in a 128-bit XMM SSE

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

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

During yum update my box crashed (I frequently have this on Centos 4 x86_64 boxes) ---> Package kdebase.x86_64 6:3.3.1-5.8 set to be updated --> Running transaction check --> Processing Dependency: system-config-printer = 0.6.116-1.centos4.1 for package: system-config-printer-gui --> Processing Dependency: glibc-devel = 2.3.4-2.9 for package: nptl-devel --> Processing Dependency: