Re: [R-sig-Debian] R 3.6.0 for Debian buster
> Dirk Eddelbuettel writes: > On 10 May 2019 at 13:46, Kurt Hornik wrote: > | > Dirk Eddelbuettel writes: > | > | > On 10 May 2019 at 10:52, Johannes Ranke wrote: > | > | 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)? > | > | > Again, that would happen in the sources you pick up from me, and per > | > | > part1 > https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c > | > 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 > make > | > | > these changes? > | > | > | > | It seems to me this is of relevance for for Sébastien (Ccing), or more > | > | generally for debian-science. > | > | > Not really. I do not think anybody concluded our LAPACK/BLAS needed to be > | > recompiled. The discussion about this has been going on for a few weeks > and > | > is now also between gcc/gfortran upstream and the lapack folks. See > Tomas's > | > posts on (IIRC) r-devel. > | > | > So in short, things are moving, and in the right direction. Also worth > | > recalling that the _initial findings_ were and still are about a gcc / > | > gfortran version _not even in Debian unstable yet_ (but the folks in > | > Fedora once again jumped the gun and they now have that problem with > | > gfortran 9). > | > | Afaics, the issue certainly affects current gfortran-8 in testing? > Correct -- my bad. As Debian pulled that upstream patch in. In any > event I was planning to push an updated r-base package carrying the > patch to configure. Thanks. Btw, Tomas just told R Core that * I had a quick look at reference lapack builds in different distributions: looking at the disassembly, and specifically for dposv tail-calling into dpotrs. I checked the latest packages from Fedora 30, Fedora Rawhide (the same?), Ubuntu 19.04, Debian Sid, OpenSuse Leap 42.3. None of the builds had that problem (yet). I've been looking for the packages via pkgs.org. * so we should be safe re BLAS/LAPACK binary packages in testing for now. (But of course, this might change in case of rebuilds using current gfortran-8). Best -k > And the as-discussed issue with noisy "verboten compiler switches" warning we > are being handed between Debian imposing switches and R not liking them. > Dirk > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R 3.6.0 for Debian buster
On 10 May 2019 at 13:46, Kurt Hornik wrote: | > Dirk Eddelbuettel writes: | | > On 10 May 2019 at 10:52, Johannes Ranke wrote: | > | 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)? | | > Again, that would happen in the sources you pick up from me, and per | | > part1 https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c | > 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 make | > | > these changes? | > | | > | It seems to me this is of relevance for for Sébastien (Ccing), or more | > | generally for debian-science. | | > Not really. I do not think anybody concluded our LAPACK/BLAS needed to be | > recompiled. The discussion about this has been going on for a few weeks and | > is now also between gcc/gfortran upstream and the lapack folks. See Tomas's | > posts on (IIRC) r-devel. | | > So in short, things are moving, and in the right direction. Also worth | > recalling that the _initial findings_ were and still are about a gcc / | > gfortran version _not even in Debian unstable yet_ (but the folks in | > Fedora once again jumped the gun and they now have that problem with | > gfortran 9). | | Afaics, the issue certainly affects current gfortran-8 in testing? Correct -- my bad. As Debian pulled that upstream patch in. In any event I was planning to push an updated r-base package carrying the patch to configure. And the as-discussed issue with noisy "verboten compiler switches" warning we are being handed between Debian imposing switches and R not liking them. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R 3.6.0 for Debian buster
> Dirk Eddelbuettel writes: > On 10 May 2019 at 10:52, Johannes Ranke wrote: > | 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)? > Again, that would happen in the sources you pick up from me, and per > part1 > https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c > 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 make > | > these changes? > | > | It seems to me this is of relevance for for Sébastien (Ccing), or more > | generally for debian-science. > Not really. I do not think anybody concluded our LAPACK/BLAS needed to be > recompiled. The discussion about this has been going on for a few weeks and > is now also between gcc/gfortran upstream and the lapack folks. See Tomas's > posts on (IIRC) r-devel. > So in short, things are moving, and in the right direction. Also worth > recalling that the _initial findings_ were and still are about a gcc / > gfortran version _not even in Debian unstable yet_ (but the folks in > Fedora once again jumped the gun and they now have that problem with > gfortran 9). Afaics, the issue certainly affects current gfortran-8 in testing? -k ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R 3.6.0 for Debian buster
On 10 May 2019 at 10:52, Johannes Ranke wrote: | 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)? Again, that would happen in the sources you pick up from me, and per part1 https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c 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 make | > these changes? | | It seems to me this is of relevance for for Sébastien (Ccing), or more | generally for debian-science. Not really. I do not think anybody concluded our LAPACK/BLAS needed to be recompiled. The discussion about this has been going on for a few weeks and is now also between gcc/gfortran upstream and the lapack folks. See Tomas's posts on (IIRC) r-devel. So in short, things are moving, and in the right direction. Also worth recalling that the _initial findings_ were and still are about a gcc / gfortran version _not even in Debian unstable yet_ (but the folks in Fedora once again jumped the gun and they now have that problem with gfortran 9). Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R 3.6.0 for Debian buster
Kurt, Am Donnerstag, 9. Mai 2019, 16:35:24 CEST schrieb Kurt Hornik: > > Johannes Ranke writes: > Johannes, > > It seems that one can avoid the gfortran problems with Fortran > BLAS/LAPACK implementations by compiling with > -fno-optimize-sibling-calls. ... > 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. 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 > these changes? It seems to me this is of relevance for for Sébastien (Ccing), or more generally for debian-science. Kind regards, Johannes > > Best > -k > > > 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 > >> >> using a Fortran interface (and hence in particular when using the BLAS > >> >> and LAPACK sources that ship with R). > >> > > >> > No, I wasn't aware of this. Is there a bug report where this is > >> > discussed? > >> > >> Not really, as the issue seems to complicated to condense into a bug > >> report. From discussions with Thomas Koenig from the GCC team, it seems > >> that f2c, g77 and now gfortran have always added additional character > >> length arguments for each character argument, where the R > >> F77_NAME/F77_CALL mechanism has always called with the arguments of the > >> Fortran subroutine but without the additional length arguments. A > >> change in gcc trunk also ported to gcc-8-branch apparently changed what > >> happened in such case, to the effect that we're now seeing about 25 > >> CRAN packages fail their run time checks with segfaults or run time > >> errors ... > >> > >> But things are actually hard to pin down for us, and no obvious "fix" > >> is in sight. It would be great if at least for the gfortran-8 that > >> Debian will release we would get the old behavior back ... > > > > I think the likelihood of this would be greater if there was a bug against > > the version of gfortran in unstable/testing... Can you give a small > > reproducible example? > > > > Johannes > > > >> Best > >> -k > >> > >> > Johannes > >> > > >> >> It seems I can avoid these using > >> >> OpenBLAS (but then this really only works find for me provided I > >> >> setenv > >> >> OPENBLAS_NUM_THREADS=1). > >> >> > >> >> -k > >> >> > >> >> > Dear all, > >> >> > Now that the upcoming Debian release "buster" is frozen, I have > >> >> > started > >> >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 > >> >> > is > >> >> > now > >> >> > available for Debian buster on i386 and amd64 architectures. Please > >> >> > refer > >> >> > to> > >> >> > > >> >> > https://cran.r-project.org/bin/linux/debian/ > >> >> > > >> >> > for details. At the moment I am not providing binaries for the arm > >> >> > architecture for buster, as the SD card in my raspberry 3 has died > >> >> > and > >> >> > I > >> >> > do > >> >> > not use these binaries any more anyways. Let me know if this is a > >> >> > problem. > >> >> > > >> >> > Kind regards, > >> >> > > >> >> > Johannes > >> >> > > >> >> > ___ > >> >> > R-SIG-Debian mailing list > >> >> > R-SIG-Debian@r-project.org > >> >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian > >> > >> ___ > >> R-SIG-Debian mailing list > >> R-SIG-Debian@r-project.org > >> https://stat.ethz.ch/mailman/listinfo/r-sig-debian -- PD Dr. Johannes Ranke Grenzach-Wyhlen ___ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
