search for: refblas

...1d4481a770ec15c > part2 https://github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030 > it only affects gfortran >= 7, and my Debian stable fileserver shows gcc > still the default so no rush. > | > In principle I think all Fortran BLAS/LAPACK implementations (refblas > | > and ATLAS) packaged for buster should be recompiled with > | > -fno-optimize-sibling-calls (they may be fine in case they were compiled > | > with older version of gfortran-8, but then the next rebuild will cause > | > trouble): Dirk, any chance you could get the packa...

....6.0 backports for buster. Thanks, that sounds good. But I need some help as I do not know much about autoconf and Debian packaging: Is it enough to patch configure.ac (r76467) or do we need to update configure as well (r76468)? > In principle I think all Fortran BLAS/LAPACK implementations (refblas > and ATLAS) packaged for buster should be recompiled with > -fno-optimize-sibling-calls (they may be fine in case they were compiled > with older version of gfortran-8, but then the next rebuild will cause > trouble): Dirk, any chance you could get the package maintainers to make >...

Am Montag, 29. April 2019, 15:03:54 CEST schrieb Kurt Hornik: > >>>>> Johannes Ranke writes: > > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik: > >> >>>>> Johannes Ranke writes: > >> Thanks. You may have seen that with current gfortran in > >> testing/unstable, there are problems with the R BLAS/LAPACK API entries

...2d3f404cc970ab33ebee1d4481a770ec15c part2 https://github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030 it only affects gfortran >= 7, and my Debian stable fileserver shows gcc still the default so no rush. | > In principle I think all Fortran BLAS/LAPACK implementations (refblas | > and ATLAS) packaged for buster should be recompiled with | > -fno-optimize-sibling-calls (they may be fine in case they were compiled | > with older version of gfortran-8, but then the next rebuild will cause | > trouble): Dirk, any chance you could get the package maintainers to ma...

...15c | > part2 https://github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030 | | > it only affects gfortran >= 7, and my Debian stable fileserver shows gcc | > still the default so no rush. | | > | > In principle I think all Fortran BLAS/LAPACK implementations (refblas | > | > and ATLAS) packaged for buster should be recompiled with | > | > -fno-optimize-sibling-calls (they may be fine in case they were compiled | > | > with older version of gfortran-8, but then the next rebuild will cause | > | > trouble): Dirk, any chance you could get t...

> version _ platform i386-pc-linux-gnu arch i386 os linux-gnu system i386, linux-gnu status major 2 minor 1.0 year 2005 month 04 day 18 language R OS:debian linux # R CMD INSTALL /home/ronggui/Matrix_0.96-3.tar.gz ......... s-3 -L/usr/lib/R/lib -lR /usr/bin/ld: cannot find -lblas-3 collect2: ld returned 1 exit status make: *** [Matrix.so] Error 1

Hi, I'm using Ubuntu Hardy i386, and the R 2.7.1 Ubuntu packages from CRAN. The CRAN r-base-dev package depends on refblas3-dev or atlas3-base-dev, but octave3.0-headers depends on libblas-dev. The two blas packages seem to conflict, so r-base-dev and octave3.0-headers can't be installed together. Is this a known issue? Thanks, Gad $ sudo apt-get install octave3.0-headers Reading package lists... Done Buildin...

...illa/show_bug.cgi?id=90329 for more information. Yesterday I changed R-devel and R-patched to use -fno-optimize-sibling-calls for gfortran >= 7: it would be great if you could pull this change into the R 3.6.0 backports for buster. In principle I think all Fortran BLAS/LAPACK implementations (refblas and ATLAS) packaged for buster should be recompiled with -fno-optimize-sibling-calls (they may be fine in case they were compiled with older version of gfortran-8, but then the next rebuild will cause trouble): Dirk, any chance you could get the package maintainers to make these changes? Best -k...

...github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030 > | > | > it only affects gfortran >= 7, and my Debian stable fileserver shows gcc > | > still the default so no rush. > | > | > | > In principle I think all Fortran BLAS/LAPACK implementations (refblas > | > | > and ATLAS) packaged for buster should be recompiled with > | > | > -fno-optimize-sibling-calls (they may be fine in case they were compiled > | > | > with older version of gfortran-8, but then the next rebuild will cause > | > | > trouble): Dirk, any ch...

Dear All, Summary: ======== To test some packages, I want to build R-3.1.0 (current R devel). However, when I use the default libblas, make check fails with running code in 'reg-BLAS.R' ...make[3]: *** [reg-BLAS.Rout] Error 1 It does not fail, however, if I use libatlas3 or libopenblas. The same thing happens with the current R patched. I've google around and cannot find

...i?id=90329 | | for more information. | | Yesterday I changed R-devel and R-patched to use | -fno-optimize-sibling-calls for gfortran >= 7: it would be great if you | could pull this change into the R 3.6.0 backports for buster. | | In principle I think all Fortran BLAS/LAPACK implementations (refblas | and ATLAS) packaged for buster should be recompiled with | -fno-optimize-sibling-calls (they may be fine in case they were compiled | with older version of gfortran-8, but then the next rebuild will cause | trouble): Dirk, any chance you could get the package maintainers to make | these changes?...