I am working on an R library submitted to CRAN, where it compiles on all the platforms but Solaris.
Thanks to The R-hub builder website, I was able to get two different types of errors on that system (otherwise I have no access to any Solaris machine).
However, I have no idea about the error that I get. Moreover, the behaviour with two compilers is quite different:
-
Using the option: "Oracle Solaris 10, x86, 32 bit, R-release", my code compiles but it crashes at runtime with a "segfault".
-
Using the option: "Oracle Solaris 10, x86, 32 bit, R-release, Oracle Developer Studio 12.6", the code does not even compile, getting a strange error:
"rcpp_module.cpp", line 340: Error: The name function is ambiguous, void Rcpp::function<RESULT_TYPE>(const char*, RESULT_TYPE()(), const char) and std::function<_Signature>.
Since the package compiles (with zero warnings) and executes on Windows, Ubuntu, CentOs, Mac OS X, but I have no clue about what should I look for as possible errors.
Did anyone else have the same problems? Do you have any hints?
Thanks for any support.
UPDATED ON 30.04.2021: I have worked out a minimal example reproducing the error for on R-hub builder for the system Oracle Solaris 10, x86, 32 bit, R-release, Oracle Developer Studio 12.6. The results are available here.
In the rcpp_module.cpp file we have:
#include <Rcpp.h>
#include "KWD_Histogram2D.h"
Rcpp::List compareAll(Rcpp::NumericMatrix Coordinates, // This is line 49
Rcpp::NumericMatrix Weights, int L = 3,
bool recode = true, const std::string& method = "approx",
const std::string& algorithm = "colgen",
const std::string& model = "mincostflow",
const std::string& verbosity = "silent",
double timelimit = 14400, double opt_tolerance = 1e-06,
bool unbalanced = false, double unbal_cost = 1e+09,
bool convex = true) {
Rcpp::List sol;
return sol;
}
RCPP_MODULE(SKWD) {
using namespace Rcpp;
function("compareAll", &compareAll,
List::create(_["Coordinates"], _["Weights"], _["L"] = 3,
_["recode"] = true, _["method"] = "approx",
_["algorithm"] = "colgen", _["model"] = "mincostflow",
_["verbosity"] = "silent", _["timelimit"] = 14400,
_["opt_tolerance"] = 1e-06, _["unbalanced"] = false,
_["unbal_cost"] = 1e+09, _["convex"] = true),
"compare all histograms using the given search options");
}
The included file KWD_Histogram2D.h is basically empty.
The error the R-hub outputs is as follows:
"rcpp_module.cpp", line 49: Error: The name function is ambiguous, void Rcpp::function<RESULT_TYPE>(const char*, RESULT_TYPE(*)(), const char*) and std::function<_Signature>.
1 Error(s) detected.
UPDATED ON 02.05.2021: The previous error vanishes after re-running the command Rcpp::compileAttributes()
which rewrite the files RcppExports.cpp
and RcppExports.R
. However, even the basic Rcpp tutorial example with the Student class does not work on Solaris with Oracle Developer Studio 12.6. Now the error is similar to the following one:
Error: package or namespace load failed for ‘RcppStudent’ in .doLoadActions(where, attach): error in load action .__A__.1 for package RcppStudent: loadModule(module = "RcppStudentEx", what = TRUE, env = ns, loadNow = TRUE): Unable to load module "RcppStudentEx": negative length vectors are not allowed Error: loading failed Execution halted
I have just reported this issue at rcpp-modules-student.
UPDATED ON 03.05.2021: My C++ code compiles and runs correctly under Solaris 11 (via VirtualoBox) using gcc-5.5 installed via OpenCSW. Hence, the bug lies somewhere in between the Rcpp wrapper I wrote, and the R system running under Solaris.
UPDATED ON 07.05.2021: I have answered to my own question below.
2
Answers
The only way to reproduce the issue that was happening on the CRAN automated build system was to install locally a Solaris 10 in VirtualBox using the image available at https://files.r-hub.io/solaris/ and updating the version of R following the instructions described in the solarischeck GitHub repository.
In the end, the error was in my code, since a dangerous logical expression between floating-point numbers was causing an infinite recursive call, and hence, there was an overflow of the C stack.
The issue was raised by Solaris by pure chance.
in the code on Github on line 335-340
Should not be the second nodes?