similar to: problems compiling for RHEL 5.3 x86_64

So, tried again from scratch. Again, CentOS 5.3, which is essentially RHEL 5.3. ./configure --with-blas="-L/opt/acml4.3.0/gfortran64/lib -lacml" In config.log, get things like configure:37199: checking for dgemm_ in -L/opt/acml4.3.0/gfortran64/lib -lacml configure:37230: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c

So, I tried the following configure: ./configure --with-lapack --with-blas --with-tcltk No use of ACML at all, but both lapack and blas. Configure proceeds without any errors. Make, same thing. Make check - same problem with stats. But, this time a .fail file got created in tests/Example. Bottom of the file has something which might resonate with someone out there: Error in La.svd(x, nu,

Greetings - For a host of reasons I chose (was forced) to upgrade my multi-Opteron box from Fedora 7 -> Fedora 8. In the process, I also updated the ACML I had installed from 4.0.0 to 4.1.0. While I get no errors (that I can find) in the config -> make -> make install sequence, I'm pretty sure (based on some benchmarks) that I'm not getting BLAS and/or Lapack to compile in. So,

Normally, I do the following to configure R for compilation on my Opteron box with ACML installed: ./configure --with-tcltk --with-blas="-L/opt/acml4.3.0/gfortran64/lib -lacml" However, when I do so, and look at Makeconf, I see BLAS_LIBS = -lblas I thought I would see BLAS_LIBS = -L/opt/acml4.3.0/gfortran64/lib -lacml Why isn't Makeconf picking up the right BLAS_LIBS (or is

Dear All, Under Debian GNU/Linux La.svd (with method = "dgesdd") sometimes gives the error "Error in La.svd(data, nu = 0, nv = min(nrow, ncol), method = "dgesdd") : LAPACK routine DGESDD gave error code -12" It seems not to depend on the data per se, but on the relationship between numbers of rows and columns. For example, if the number of columns is 100,

Have been running 2.5.1 on my multi-pro Opteron box running Fedora Core 5 with no problems. Had compiled previously with no problems. However, for a variety of reasons (mostly due to ACML upgrade), I tried a recompile using the following sequence of commands (note I'm compiling in ACML support for blas): LD_LIBRARY_PATH=/opt/acml3.6.1/gfortran64/lib export LD_LIBRARY_PATH ./configure

I'm trying to build R-devel with AMD's ACML. I downloaded version 3.0.0 64bit for gfortran (acml-3-0-0-gfortran-64bit.tgz) and copied the libraries to /usr/local/lib. When I configure R to build against the ACML library, how do I know if the library has been detected and will be used? I run 'configure' with the '--with-blas=-lacml' flag and am using gcc 4.0.2 (with

Greetings - I'm trying to compile R under GNU/Linux (RHEL 4) on a multi-Opteron box, with ACML support. First, I downloaded and installed ACML 3.5 - GNU version, although I'm not entirely sure what the differences are - from the AMD website. The ACML libraries were installed to /opt/acml3.5.0/ Second, I ran ./configure --with-blas='-lacml' The configure went fine,

Lately I'm getting this error quite a bit: Error in La.svd(x, nu, nv) : error code 1 from Lapack routine 'dgesdd' I'm running R 2.5.0 on a 64 bit Intel machine running Fedora (8 I think). Maybe the 64 bit platform is more fragile about declaring convergence. I'm seeing way more of these errors than I ever have before. From R-Help I see that this issue comes up from time to

Dear R helpers, I am working with R 2.4.1 GUI 1.18 (4038) for MacOSX. I have a matrix of 10 000 genes and try to run the following commands: > model.mix<-makeModel (data=data, formula=~Dye+Array+Sample+Time, random=~Array+Sample) > anova.mix<-fitmaanova (data, model.mix) > test.mix<-matest (data, model=model.mix, term="Time", n.perm=100, test.method=c(1,0,1,1))

Error in La.svd(x, nu, nv) : error code 1 from Lapack routine ‘dgesdd’ what resources are there to track down errors like this [[alternative HTML version deleted]]

Hi, I'm having problems using ACML with R. I made two changes in config.site by setting LDFLAGS="-L/opt/acml3.1.0/gnu64/lib" BLAS_LIBS="-lacml" ./config and make go through but when I try to use the lm() function, I get the error message Error in chol2inv(Qr$qr[p1, p1, drop = FALSE]) : lapack routines cannot be loaded In addition: Warning message: unable to load

Hello R-users, during one of my analyses that involve a SVD, I get the following error message: Error in La.svd(x, nu, nv, method) : error code 1 from Lapack routine dgesdd With a search on the R web site, I only found references to error codes 17 and 3 for this particular routine. I also found the Lapack web site, but could not find a list of the possible error messages. If somebody knows what

I am attempting to perform a pca on a data frame of dimension 5000x19, but when I execute pcapres<-prcomp(pres,center=TRUE) the following error message is returned: Error in La.svd(x, nu, nv, method) : error code 18 from Lapack routine dgesdd Where am I going wrong? I am running R-1.8.0 on Debian. Regards, Laura

I am encountering segfaults when checking the lme4 package on an Athlon64 system if I use the acml blas. R was built as a 64-bit application using the GCC 4.0.3 compiler suite including gfortran. The version of acml is 3.5.0 gfortran64. I do not encounter the segfaults when I compile R with R's built-in BLAS. The errors occur in the first example in lme4 in a call to lmer. It looks like

Hi, I'm just wondering if it is planned to include the Lapack routine DGESDD (and friends) in R-1.4.0? This is faster (supposedly by a factor of ~6 for large matrices) than DGESVD which is currently (R-1.3.1) called by La.svd. And if it is not in the plans yet, is there a chance it could be? I've added it to my local version of R-1.3.1 and so far see a factor of 4 improvement over

Hi, I wonder where I can find an example of using a function in LAPACK library in a user's own C code. I wrote a C program which will be compiled and linked to produce a DLL file and then loaded into R. I hope to use a function from LAPACK library, for example, dgesdd, in the program. Following R manual, I call the function by F77_CALL(dgesdd) in the program. The program can be compiled

Dear all I have a big matrix of standardized values (dimensions 285x5829) and R fails to calculate the principal components using prcomp() with the following error message: pc <- prcomp(my.matrix) Error in La.svd(x, nu, nv, method) : error code 1 from Lapack routine dgesdd Is the matrix too big? I'm using R-1.8.1 under Unix (Solaris8) and Linux(Suse 8.2). I tried to perform a principal

While I recently received some very helpful files and email from Kevin Hendricks for compiling with ATLAS, thought I'd first have a stab at ACML. Having problems, which I suspect are trivial to solve: 1. machine is running RHEL 4, meaning, it uses gcc 3.4.5 out of the box, and g77. In my experience, over-riding RHEL's choice, and manually upgrading to gcc 4.x.x (and, as a consequence

Dear all, Has anyone seen the same problem? I tried compiling R-1.9.0 alpha (2004-03-16) on our Opteron box running SUSE Linux ES8. I ran: ./configure --enable-R-shlib --with-blas=goto and got: Source directory: . Installation directory: /usr/local C compiler: gcc -m64 -O2 -g -msse2 -march=k8 -Wall --pedantic C++ compiler: g++ -m64 -O2 -g