[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