I think I got confused by the fact that the second line of
https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
is "Solaris 10 on ix64/x64".
I interpreted that as "64-bit Solaris". On the other hand the rest
of the information in that file says that the default ODS compiler used
is a 32-bit build; it doesn't say anything about the build of the
alternative gcc compiler (which is used for packages with Rcpp etc.)
Other comments farther down in the file (about versions of Java,
protobuf used) do suggest that the system is indeed 32-bit.
If the CRAN Solaris platform is indeed 32-bit, then I really have no
idea why checks are failing on CRAN but succeeding on r-hub (but I also
feel better about not trying to fix it ...)
I do appreciate the provision of the resources for setting up a
virtual Solaris box - I don't recall exactly what hurdle I encountered
last time I tried, it was probably some weird idiosyncratic thing.
For the record I haven't tried valgrind recently, but the CRAN
versions of the valgrind tests weren't throwing any errors ...
https://cran.r-project.org/web/checks/check_issue_kinds.html
thanks
Ben Bolker
On 9/15/21 2:19 AM, Gábor Csárdi wrote:
Hi Ben,
According to https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86
CRAN's Solaris is also 32 bit.
But maybe I am missing something?
You can download a Solaris VM (for Virtualbox or VMware) from
https://files.r-hub.io/solaris/
It has both 32 bit and 64 bit R (with gcc) and ODS R as well. You can
update R on it like this:
https://github.com/r-hub/solarischeck/tree/master/packer#updating-r
Best,
Gabor
On Wed, Sep 15, 2021 at 1:51 AM Ben Bolker wrote:
I may have asked something like this before, but ...
The glmmTMB package is currently segfaulting (on the very first example)
on its CRAN Solaris checks
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/glmmTMB-00check.html
> ## Comparing variance-covariance matrix with manual computation
> data("sleepstudy",package="lme4")
> fm4 <- glmmTMB(Reaction ~ Days + (Days|Subject), sleepstudy)
*** caught segfault ***
address 4539ec45, cause 'memory not mapped'
---
We have to submit a new version to CRAN soon; we will most likely beg
the CRAN maintainers' indulgence for having it fail on Solaris, but it
would be nice to fix it if we can.
The CRAN Solaris platform is 64-bit x86_64, using gcc/g++ because
the package uses Rcpp.
The package builds/checks fine on the r-hub `solaris-x86-patched`
platform, which is identical as far as I can tell **except** 32-bit
rather than 64-bit.
Short of installing 64-bit Solaris in a VM (which I have not done yet
because of random compatibility/command-line bullshittery that put me
off), does anyone have any wisdom to share for diagnosing and/or
guessing what the problem is?
Here are some links to similar errors, none of them seem terribly
useful/relevant.
https://github.com/gagolews/stringi/issues/94
https://mran.microsoft.com/snapshot/2017-07-05/web/checks/check_results_vcfR.html
https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/prt-00check.html
glmmTMB is built on a pretty big stack (Eigen, Rcpp, RcppEigen,
CppAD, TMB) - the problem could be somewhere in there (the TMB package
runs no tests and very few examples on CRAN, so there could be problems
there that only get flagged when we try glmmTMB examples).
More discussion at
https://github.com/glmmTMB/glmmTMB/issues/732 (with some red herrings)
if anyone is interested.
cheers
Ben Bolker
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
Graduate chair, Mathematics & Statistics
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
