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

Reply via email to