[R-pkg-devel] Working with R-devel
wdunlap at tibco.com
Wed Jan 24 16:55:16 CET 2018
On Linux you can trace all the getenv calls with ltrace. It only
works on ELF files, not sh scripts:
% R CMD ltrace -e getenv `R RHOME`/bin/*/R
On Wed, Jan 24, 2018 at 6:11 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
> On 24 January 2018 at 07:03, luke-tierney at uiowa.edu wrote:
> | If you are picking up an R 3.4.x that is trying to load a package
> | built by R-devel you should also see a warning that the package was
> | built under R version 3.5.0
> Yes, I am of course very aware of the issue.
> But we had to separate out R-release and R-devel for years, and so I did. I
> had separate libPaths (or, at least, leading component) for R-devel because
> of that.
> | If you are not, then you could be picking up an older R-devel from
> | before the internals change. Probably more likely, the Rcpp being
> | loaded at that point was built by 3.4.x, which would suggest library
> | path settings are messed up at that point, but not clear why. [It
> | might be possible and useful to provide more information about the
> | broken pieces in the error message but I won't have time to look any
> | time soon.]
> | At the moment when it matters I usually use
> | env R_LIBS=<my R-devel library> R CMD check ...
> | for checks under R_devel
> It was the R_LIBS_USER (which used to work) to R_LIBS change that got plus
> the fact that my R-devel was picking up my R-release check.Renviron. The
> from Martin got rid of that.
> Sometimes I wonder if we should have an extra-verbose mode that picks up
> EVERY single Sys.getenv() and alike to make it easier to trace this. But
> run-time cost of the check is probably unattractive.
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> R-package-devel at r-project.org mailing list
[[alternative HTML version deleted]]
More information about the R-package-devel