[Rd] gfortran 9 quantreg bug
Kasper Daniel Hansen
k@@perd@n|e|h@n@en @end|ng |rom gm@||@com
Tue Aug 6 16:33:49 CEST 2019
Dirk,
Thanks for the blog post on this, and the pointers in this email.
I have a question: it seems to me that you end up using a different
compiler for the package (quantreg) than was used to build R itself. As I
understand ABI changes, this is considered unsupported (ok, that depends on
what version of gcc/gfortran was used to build R, but there has been a lot
of ABI changes in GCC). Is that correct? I understand that this shortcut
makes it much easier to use different compilers, and might work for Roger's
usecase, but I was wondering about this issue of using a different compiler
for packages. Is this something I should worry about?
Best,
Kasper
On Sun, Aug 4, 2019 at 10:41 AM Dirk Eddelbuettel <edd using debian.org> wrote:
>
> Roger,
>
> On 4 August 2019 at 06:48, Koenker, Roger W wrote:
> | I’d like to solicit some advice on a debugging problem I have in the
> quantreg package.
> | Kurt and Brian have reported to me that on Debian machines with gfortran
> 9
> |
> | library(quantreg)
> | f = summary(rq(foodexp ~ income, data = engel, tau = 1:4/5))
> | plot(f)
> |
> | fails because summary() produces bogus estimates of the coefficient
> bounds.
> | This example has been around in my R package from the earliest days of
> R, and
> | before that in various incarnations of S. The culprit is apparently
> rqbr.f which is
> | even more ancient, but must have something that gfortran 9 doesn’t
> approve of.
> |
> | I note that in R-devel there have been some other issues with gfortran
> 9, but these seem
> | unrelated to my problem. Not having access to a machine with an
> R/gfortran9
> | configuration, I can’t apply my rudimentary debugging methods. I’ve
> considered
> | trying to build gfortran on my mac air and then building R from source,
> but before
> | going down this road, I wondered whether others had other suggestions, or
> | advice about my proposed route. As far as I can see there are not yet
> | binaries for gfortran 9 for osx.
>
> Maybe installing and running Docker on your mac is an alternative?
>
> Minimally viable example using
>
> a) docker (on Linux, but it is portable) and
>
> b) the current official 'r-base' container (an alias to our Rocker
> r-base container)
>
> r-base is begged to Debian testing, and also allows you to get Debian
> unstable. Below I fire up the container, tell it to use bash (not R) and
> update
>
> edd using rob:~/git$ docker run --rm -ti r-base bash
> root using 1307193fadf4:/#
> root using 1307193fadf4:/# apt-get update
> Get:1 http://cdn-fastly.deb.debian.org/debian sid InRelease [149 kB]
> Get:2 http://cdn-fastly.deb.debian.org/debian testing InRelease [117 kB]
> Get:3 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages
> [8,385 kB]
> Get:4 http://cdn-fastly.deb.debian.org/debian testing/main amd64
> Packages [7,918 kB]
> Fetched 16.6 MB in 4s (4,649 kB/s)
> Reading package lists... Done
> root using 1307193fadf4:/# apt-cache policy gcc-9
> gcc-9:
> Installed: (none)
> Candidate: 9.1.0-10
> Version table:
> 9.1.0-10 990
> 990 http://deb.debian.org/debian testing/main amd64 Packages
> 500 http://http.debian.net/debian sid/main amd64 Packages
> root using 1307193fadf4:/# apt-cache policy gfortran-9
> gfortran-9:
> Installed: (none)
> Candidate: 9.1.0-10
> Version table:
> 9.1.0-10 990
> 990 http://deb.debian.org/debian testing/main amd64 Packages
> 500 http://http.debian.net/debian sid/main amd64 Packages
> root using 1307193fadf4:/#
>
> At this point it just a matter of actually installing gcc-9 and gfortran-9
> (via apt-get install ...), and setting CC, FC, F77 and whichever other
> environment variables the R build reflect to build quantreg.
>
> That said, this will be Debian's standard gfortran-9. What is at times a
> little frustrating is that some of the builds used by some of the CRAN
> tests
> use local modifications which make their behaviour a little harder to
> reproduce. I have an open issue with my (also old and stable) digest
> package
> which goes belly-up on a clang-on-Fedora build and nowhere else -- and I
> have
> been unable to reproduce this too.
>
> For such cases, having Docker container would be one possible way of
> giving access to the test environment to make it accessible to more users.
>
> Best, Dirk
>
>
> |
> | Thanks,
> | Roger
> |
> | Roger Koenker
> | r.koenker using ucl.ac.uk<mailto:r.koenker using ucl.ac.uk>
> | Department of Economics, UCL
> | London WC1H 0AX.
> |
> |
> |
> | [[alternative HTML version deleted]]
> |
> | ______________________________________________
> | R-devel using r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Best,
Kasper
[[alternative HTML version deleted]]
More information about the R-devel
mailing list