<div dir="ltr">On Mon, Sep 30, 2013 at 3:56 PM, Dirk Eddelbuettel <span dir="ltr"><<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 30 September 2013 at 16:46, Sul, Young L wrote:<br>
| I know that from <a href="http://cran.fhcrc.org/web/checks/check_results_RcppEigen.html" target="_blank">http://cran.fhcrc.org/web/checks/check_results_RcppEigen.html</a><br>
</div>| RcppEigen isn?t compilable until Solaris 10 yet. I?m wondering if anyone has a<br>
<div class="im">| sense if this will be fixed in the future?<br>
<br>
</div>It's tricky:<br>
<br>
  -- packages Rcpp${FOO} fail for various values of ${FOO} also because Rcpp<br>
     itself may not build (and in this particular case solaris-x86 seems to<br>
     pass for Rcpp (Yay!) but solaris-sparc still fails (booh) so here it is<br>
     indeed an RcppEigen issue)<br>
<br>
  -- none of the core member of the Rcpp group has access to either Solaris<br>
     variant (though as I recall Martyn Plummer has a solaris x86 and<br>
     provided Romain access to this in the past)<br>
<br>
  -- so we cannot fix Rcpp, nor can we fix packages building on top of Rcpp<br>
<br>
  -- and as "we" don't use these machine, fixes are not of high priority (but<br>
     if someone could provide funding, Romain may be willing to tackle this<br>
     but you'd have to ask him)<br>
<br>
However, we have always accepted patches for this.<br>
<br>
With RcppEigen, the added difficulty is that the listed maintainer is no<br>
longer all that active around R.<br></blockquote><div><br></div><div>Actually the listed maintainer was writing a reply when your reply came through :-)</div><div><br></div><div>I had been willing to bet that no one used RcppEigen on Solaris and its failing to build on Solaris was a non-issue, but Young Sui has proved me wrong.</div>
<div><br></div><div>However, the problems Dirk described hold for me too.  I don't have access to a Solaris system, either x86 or sparse, and don't know of a way that I could access such a system.  Even if I could get access I doubt that I would be able to fix the parts complained about in the logs because they are in the Eigen code   If I recall correctly the Eigen authors said they were not going to try to support Solaris because - wait for it - they don't have access to a Solaris system.</div>
<div><br></div><div>I recall a suggestion of using openSolaris under virtualbox or some other virtualization software but, according to the Wikipedia page, openSolaris no longer exists.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

So that is an open spot -- if someone ambitious enough to tackle this would<br>
step forward and adopt RcppEigen, we'd all appreciate it.<br></blockquote><div></div></div><br></div><div class="gmail_extra">Yes, I would be willing to pass RcppEigen onto another maintainer.  </div><div class="gmail_extra">
However It happens that there will be a rather complicated shuffle involving the Matrix, RcppEigen and lme4 packages in the near future and probably I should be involved in that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
The situation is that a recent release (and a minor version number at that) of the CHOLMOD software, on which the sparse Cholesky factorization in Matrix and in RcppEigen is based, added a field to the cholmod_factor_struct.  If we use the new CHOLMOD version in Matrix, which we would like to do, then the installed versions of other packages will start to fail when the new Matrix is installed.  It is going to be messy because there is no way to force an upgrade of a downstream package when a new Matrix is installed.</div>
<div class="gmail_extra"> </div></div>