[Rcpp-devel] RcppEigen not compiling under Solaris 10 INTEL

[Douglas Bates]

Change "either x86 or sparse" to "either x86 or sparc".  I write sparse
more than I write sparc and my fingers took over.


On Mon, Sep 30, 2013 at 4:20 PM, Douglas Bates <bates at stat.wisc.edu> wrote:

> On Mon, Sep 30, 2013 at 3:56 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
>>
>> On 30 September 2013 at 16:46, Sul, Young L wrote:
>> | I know that from
>> http://cran.fhcrc.org/web/checks/check_results_RcppEigen.html
>> | RcppEigen isn?t compilable until Solaris 10 yet. I?m wondering if
>> anyone has a
>> | sense if this will be fixed in the future?
>>
>> It's tricky:
>>
>>   -- packages Rcpp${FOO} fail for various values of ${FOO} also because
>> Rcpp
>>      itself may not build (and in this particular case solaris-x86 seems
>> to
>>      pass for Rcpp (Yay!) but solaris-sparc still fails (booh) so here it
>> is
>>      indeed an RcppEigen issue)
>>
>>   -- none of the core member of the Rcpp group has access to either
>> Solaris
>>      variant (though as I recall Martyn Plummer has a solaris x86 and
>>      provided Romain access to this in the past)
>>
>>   -- so we cannot fix Rcpp, nor can we fix packages building on top of
>> Rcpp
>>
>>   -- and as "we" don't use these machine, fixes are not of high priority
>> (but
>>      if someone could provide funding, Romain may be willing to tackle
>> this
>>      but you'd have to ask him)
>>
>> However, we have always accepted patches for this.
>>
>> With RcppEigen, the added difficulty is that the listed maintainer is no
>> longer all that active around R.
>>
>
> Actually the listed maintainer was writing a reply when your reply came
> through :-)
>
> 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.
>
> 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.
>
> I recall a suggestion of using openSolaris under virtualbox or some other
> virtualization software but, according to the Wikipedia page, openSolaris
> no longer exists.
>
> So that is an open spot -- if someone ambitious enough to tackle this would
>> step forward and adopt RcppEigen, we'd all appreciate it.
>>
>
> Yes, I would be willing to pass RcppEigen onto another maintainer.
> 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.
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20130930/4336c561/attachment.html>