>>>>> 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
