On Wed, 24 Jan 2018, Uwe Ligges wrote:
On 24.01.2018 12:00, Martin Maechler wrote:
Uwe Ligges <lig...@statistik.tu-dortmund.de>
on Wed, 24 Jan 2018 11:23:50 +0100 writes:
> On 24.01.2018 03:20, Dirk Eddelbuettel wrote:
>>
>> I am going in circles here and have lost my way. I used to have
means to
>> build R-devel (still do) and use it for local testing (no longer
do).
>>
>> - Fresh build of R-devel
>> - One entry in .libPaths()
>> - I can install Rcpp, it ends up in that .libPaths()
>> - I can load
>> - With the _exact same settings_ starting R as R CMD check ... I
fail on
>>
>> ** preparing package for lazy loading
>> Error : package ‘Rcpp’ was installed by an R version with different
internals; \
>> it needs to be reinstalled for use with this R version
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
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
Best,
luke
> I guess you actually pick up anotehr version of R.
> Carefully check what is on your PATH and perhaps some Renviron files
> that may be around?
> Best,
> Uwe
Yes exactly. I've been bitten many times by similar issues in
recent weeks.
The problem here is that we have so many environment variables
governing the process.
I think I have mostly solved this by the following "strategy"
(Linux/Unixy bash-like shell):
------------------------------------------
## To check: one of
env | grep '^R_'
env | grep -E '^_?R_'
## Before running:
unset R_PROFILE R_ENVIRON R_LIBS
export R_CHECK_ENVIRON=~/.R/check.Renviron_Rdevel
## where my check.Renviron* basically only sets R_LIBS
---------
[In an ideal world, R functions involved here would *not* start
other R processes... but that seems necessary for other good reasons]
The simplest one is that R can crash during a check, then you would end
uo without message where that happened, it is hard to compare timings etc.
In the real but not so ideal world, I need even a wrapper around R CMD
check to have control about the process to be able to kill it
programmaically etc.
Best,
Uwe
Martin
>>
>> which is both false (see above) and irritating.
>>
>> Does anybody have any tips, working guidelines or interpretations
of the ever
>> changing manuals (which charmingly never document what changes) ?
>>
>> Dirk
>>
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
