search for: xerbla

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 symbols (expected, I think), either way I found a reference to xerblas.o inside it but didn't know what to do with this reference. Thanks, Giuseppe Antonaci O...

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 buf[7]; strncpy(buf, srname, 6); bu...

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 'INFO'. See > >http://www.netlib.org/lapack/lug...

...al part, there was a lot of compilation before this): cp R.dll ../../bin/ -------- Building ../../bin/Rblas.dll -------- gcc -shared -s -o ../../bin/Rblas.dll blas00.o dllversion.o Rblas.def \ -L../../bin -lR -L"C:/WinNT_ATHLONSSE2" -lf77blas -latlas C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0xb): undefined refer ence to `s_wsfe' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x27): undefined refe rence to `do_fio' C:/WinNT_ATHLONSSE2/libf77blas.a(xerbla.o):xerbla.f:(.text+0x43): undefined refe rence to `do_fio' C:/WinNT_ATHLONSSE2/libf77blas....

...lapack.so dlamc.lo dlapack0.lo dlapack1.lo dlapack2.lo dlapack3.lo cmplx.lo -lf77blas -latlas -lg2c -lm -lgcc_s /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../powerpc-suse-linux /bin/ld: Error: The symbol `s_wsfe' has a R_PPC_REL24 relocation, that means '/usr/local/lib/libf77blas.a(xerbla.o)' was compiled without -fPIC. /usr/lib/gcc-lib/powerpc-suse-linux/3.3.3/../../../../powerpc-suse-linux /bin/ld: Error: The symbol `do_fio' has a R_PPC_REL24 relocation, that means '/usr/local/lib/libf77blas.a(xerbla.o)' was compiled without -fPIC. /usr/lib/gcc-lib/powerpc-suse-lin...

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 the following text: Optionally, you can install a version of ATLAS...

...as. There are quite a few warnings that were flagged, due to mismatches in function types. The prototypes that R has in its header files, for example BLAS.h, are often not compatible with gfortran function declarations. To take one small example, in src/main/print.c, we have void NORET F77_NAME(xerbla)(const char *srname, int *info) so xerbla_ is defined with two arguments. However, gfortran passes string lengths as hidden arguments. You can see this by compiling the small example $ cat xer.f SUBROUTINE FOO INTEGER INFO CALL XERBLA ('FOO', INFO) END $ gfort...

...l on several systems, there were a few failures: ------------------------------------------------------------------------ Apple Darwin 6.2 (MacOS 10.2.2) with gcc-3.2.1: gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libgslcblas.0.0.0.dylib sasum.lo saxpy.lo ... isamax.lo izamax.lo xerbla.lo -lc -install_name /usr/local/lib/libgslcblas.0.dylib -compatibility_version 1 -current_version 1.0 gcc: suppress: No such file or directory gcc: /usr/local/lib/libgslcblas.0.dylib: No such file or directory gcc: 1: No such file or directory gcc: 1.0: No such file or directory gcc: unrecognized...

...-lf77blas -latlas -L/usr/lib64 -L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3 -L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../../../lib64 -L/usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lfrtbegin -lg2c -lm -lgcc_s /usr/bin/ld: /usr/local/lib/libf77blas.a(xerbla.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libf77blas.a: could not read symbols: Bad value collect2: ld returned 1 exit status and I'm stuck to some extent. Note that the "recompile with -fPIC" must related to the cont...

...include it directly into a package and cretae a makevars or PACKAGE_LIBS...? I'm lost... The subroutine I try to use is delcols.f (http://www.maths.manchester.ac.uk/~clucas/updating/addcols.f) which calls * .. External Subroutines .. EXTERNAL DGEQRF, DLASR, DROT, DROTG, XERBLA Thank you very much!!

...me(crossprod(mm)) [1] 0.83 0.02 0.85 0.00 0.00 We have not found the Opteron to be faster than the Xeon, but the Xeon does have faster RAM... [What I did to link R against Goto's BLAS (mostly following Prof. Bates' instruction): - Install libgoto*.so and symlink to libgoto.so. - Download xerbla.f and compile to xerbla.o. - Run the R configure script with --with-blas="-lgoto /path/to/xerbla.o". - Edit Makeconf and delete the path to xerbla.o in BLAS_LIB. - make; make check ] A bit of gripe about the SUSE ES8 that was pre-loaded on the Opteron: - VNC segfault out-of-box. Needed...

...#39;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, LAPACK only has four (ilaenv, ilaenv2stage, lsamen, xerbla). The C interfaces to BLAS/LAPACK from Netlib depend on the historic behavior that explicit single-character strings are interoperable, concretely CBLAS and LAPACKE provide C interfaces/cod...

...%f\n", B[i]); } return info; } ========================== When I am trying to link to BLAS/LAPACK using gcc -std=gnu99 solve.c -o test -I$R_HOME/include -L$R_HOME/lib -lRblas -lRlapack -lgfortran linker generates an error message $RHOME/lib/libRblas.so: undefined reference to `xerbla_' Dumping symbol table shows that indeed libRblas.so has undefined xerbla_ symbol and so does libRlapack. Confusingly, documentation says that xerbla is error checking routine for BLAS, but it is not found in the library libRblas. I did find out that xerbla is defined in libR.so and w...

...lly configured but I encountered another problem while make: gcc -shared -L/usr/local/lib64 -o libRlapack.so dlamc.lo dlapack0.lo dlapack1.lo dlapack2.lo dlapack3.lo cmplx.lo -lf77blas -latlas -lg2c -lm -lgcc_s /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/libf77blas.a(xerbla.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/libf77blas.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [libRlapack.so] Erro...

...esults: $ make creating src/scripts/R.fe config.status: creating src/include/config.h config.status: src/include/config.h is unchanged Rmath.h is unchanged gcc -std=gnu99 -shared -L/usr/local/lib -o libRblas.so blas.o cmplxblas.o -L/usr/local/lib/gcc-lib/x86_64-portbld-freebsd6.0/4.0.3 -lf95 -lm # xerbla.o /usr/bin/ld: /usr/local/lib/gcc-lib/x86_64-portbld-freebsd6.0/4.0.3/libf95.a(ff.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/local/lib/gcc-lib/x86_64-portbld-freebsd6.0/4.0.3/libf95.a: could not read symbols: Bad value *** Error code 1 Stop i...

...ory `/state/partition1/apps/packages/R-2.3.0/src/modules/lapack' gcc -shared -L/usr/local/lib64 -o libRlapack.so dlamc.o dlapack0.o dlapack1.o dlapack2.o dlapack3.o cmplx.o -lf77blas -latlas -lg2c -lm -lgcc_s /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/libf77blas.a(xerbla.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/libf77blas.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [libRlapack.so] Erro...

Is there a way to exit gracefully from dynamically loaded Fortran, (several layers down), if an error condition is detected? I.e. suppose I'm within a subroutine called by a subroutine, ..., called by .Fortran(); I want to give up gracefully if an error condition is detected. If I say something like if(x .gt. 42.d0) stop then indeed everything stops, i.e. R falls over. I'd