Skip to content

[Rcpp-devel] Using "Rcpp Modules" under Solaris fails to load.

7 messages · Marius Wirths, Martyn Plummer, Dirk Eddelbuettel

Original
Dirk Eddelbuettel
# 
Hi Marius,
On 17 March 2015 at 15:26, Marius Wirths wrote:
| Hello everybody,
|  
| this is my very first post on this mailing list so if I have made any mistakes 
| please feel free to point me to it.
|  
| I have written a package for R. This package internally uses Rcpp-Modules.

Cool. So do quite a few other packages on CRAN.

| However my package got rejected from CRAN due to the fact that my package can
| not be loaded under Solaris. So, i set up a virtual machine with Solaris 10 to
| find the error in my code. For now it appears to me, that it is not possible to
| use Rcpp-Modules under Solaris using Oracle Studio 12 compilers (which are used
| by CRAN as far as i know).

I just glanced at two of mine.  Both are fine on r-patched-solaris-x86 but
fail on r-patched-solaris-sparc due to a compiler issue when dealing with
Boost headers via the BH package. I have more package with Modules on CRAN
but don't have time now to check all of them.

| I created a minimal example through:
|  
| "Rcpp.package.skeleton("somename", module=TRUE)"
|  
| I removed every file from the "src"-folder except the "Num.cpp" file and
| reduced the content of the "zzz.R" file located in the "R" folder to the single
| line "loadModule("NumEx", TRUE)".
| Compiling this minimal example with the latest version of R using the Oracle
| Studio 12 compilers results in the output given below. Also i have used the
| following enviroment variables (which are used by CRAN too):

[...]
  
| Output generated through "R CMD INSTALL ./somename" :
|  
| # R CMD INSTALL ./somename

[...]
  
| I have no idea how to solve this problem. Using the "Rcpp.package.skeleton"
| without "module=TRUE" compiles just fine (except for one warning) and can be
| loaded:

[...]

| If you need any further informations to help me please feel free to ask.


It is a tricky situation.  I don't quite know how to say this -- nobody
actively working with Rcpp has access to Solaris or interest in it (maybe
Martyn Plummer excepted).  So right now you are effectively being held
hostage over a build failure on an architecture nobody uses. 

You could stop using Modules.

Or you could add a LinkingTo: BH as your package would fail like mine. At
least that masks the other issue ;-)

Dirk
Dirk Eddelbuettel
#
On 17 March 2015 at 09:42, Dirk Eddelbuettel wrote:
| I just glanced at two of mine.  Both are fine on r-patched-solaris-x86 but
| fail on r-patched-solaris-sparc due to a compiler issue when dealing with
| Boost headers via the BH package. I have more package with Modules on CRAN
| but don't have time now to check all of them.

A counter-example is RcppCNPy. It uses Rcpp Modules, yet tests clean on
Solaris and everywhere apart from snowleopard:

   http://cran.r-project.org/web/checks/check_results_RcppCNPy.html

Now, Rcpp Modules are quite expressive and powerful, but also a little 
finicky at times. It may well be that you use a feature I do not use in
RcppCNPy.   But you could try this and see how it fares in your VM.

Dirk
Martyn Plummer
#
On Tue, 2015-03-17 at 09:42 -0500, Dirk Eddelbuettel wrote:
Well that is one interpretation. Another one is that as a testing
platform Solaris exposes weaknesses in C++ code that are not found by
other platforms due to its fastidious interpretation of the C++98
standard.

For example, Solaris Studio distinguishes between functions with C and C
++ linkage. In Marius's test package this generates multiple warnings
and may be the cause of the missing symbol, which demangles as:

Rcpp::standard_delete_finalizer<Num>(__type_0*)

As you can see, __type_0 is just a placeholder, so something went wrong
with the linkage.

Marius, if you mail me your test package I will see what it gives me.

Martyn
-----------------------------------------------------------------------
This message and its attachments are strictly confidential. If you are
not the intended recipient of this message, please immediately notify 
the sender and delete it. Since its integrity cannot be guaranteed, 
its content cannot involve the sender's responsibility. Any misuse, 
any disclosure or publication of its content, either whole or partial, 
is prohibited, exception made of formally approved use
-----------------------------------------------------------------------
Dirk Eddelbuettel
#
On 18 March 2015 at 09:45, Martyn Plummer wrote:
| Well that is one interpretation. Another one is that as a testing
| platform Solaris exposes weaknesses in C++ code that are not found by
| other platforms due to its fastidious interpretation of the C++98
| standard.

Indeed.  Which makes it even more sad that CRAN only has a budget of about
one minute for tests. So effectively a large number of tests are ... simply
turned off at CRAN.  We do not get the feedback from another compiler you
(correctly, at least "in theory") highlight here as we are being told to
suppress the tests.  Not ideal.

| Marius, if you mail me your test package I will see what it gives me.

Appreciate that.

Dirk
Dirk Eddelbuettel
#
On 18 March 2015 at 13:03, Marius Wirths wrote:
| enviroment. Dirk, your information, that there are indeed many packages using
| modules without any issues was an important information for me. So i think, it
| must be something wrong with my code. Maybe something is missing in my
| "Makevars"-file or something like that. I will investigate your package

Maybe. Maybe not. Could just be that that some facets of Modules pass on
Slowlaris whereas other trigger an error.  As I mentioned to Martyn, we
stopped running all tests years ago as we (and everybody else) were told
(with some reason, CRAN being volunteers and all...) to not run as many
tests.

You can try Rcpp itself by setting the env.var. RunAllRcppTests="yes" which
is checked for in tests/doRUnit.R -- or just alter DESCRIPTION to have a dev
version number, ie 0.11.5.1 which also tickles it (as we only ever ship release
versions format a.b.c with three components).

Dirk