enabling TBB breaks packages written by nCompiler

[paciorek]

I get messages like this:

nf <- nFunction(
                fun = function() {
                    x <- 3
                    })
writePackage(nf, pkgName = 'mytest')

R CMD build mytest

** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘mytest’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/tmp/Rtmpvj6V0L/Rinst1cb86e647bcb2d/00LOCK-mytest/00new/mytest/libs/mytest.so':
  /tmp/Rtmpvj6V0L/Rinst1cb86e647bcb2d/00LOCK-mytest/00new/mytest/libs/mytest.so: undefined symbol: _ZN3tbb10interface58internal9task_base7destroyERNS_4taskE
Error: loading failed

@perrydv I will investigate further, but if you've run into anything like this before, throw a breadcrumb my way.

[perrydv]

That must be why I had disabled the inclusion of TBB headers when not working on it.

[paciorek]

So dyn.load on the .so file is failing when done in the packaging context, but when done in Rcpp::sourceCpp (called from nCompiler:::sourceCpp_nCompiler, it is fine. The .so files from direct nCompile compilation vs. creating a package and R CMD build/INSTALL seem equivalent. Still digging...

[paciorek]

Seems to relate to what DLLs have been loaded at the point that one tries to load the .so file of interest.

After further digging, I think we need to follow these RcppParallel instructions. When I do that things are fine. (And actually on my linux machine, all I need to do is add importFrom(RcppParallel, RcppParallelLibs) to the mytest NAMESPACE file. That seems weird; oh well.)

We'll also want to test that creating a package that actually uses parallel_for works, but I am leaving that aside from this issue.

[perrydv]

Thanks @paciorek . This is encouraging. We have a good place to generate the importsFrom statement. We do not currently use Makevars files, but we do have a way to set environment variables so we can try that route.

[paciorek]

Ok, I am implementing this in tbb-pkging. Things look good after I do that in terms of creating and using a package (including when parallel_for is used in the package code).

However, I'll note that setting the environment variables via $env in the plugin does not seem to have any effect on how a package generated by nCompiler (via writePackage or nCompile(...,package=TRUE) is built/installed. I.e., even though // [[Rcpp::plugins(nCompiler_Eigen_plugin)]] is in the .cpp file, I don't see that compiler flags used when installing the generated source package are affected by what is in $env.

Given that the RcppParallel::RcppParallelLibs() returns nothing for Linux/Mac, the key thing to check may be that a generated package on Windows behaves correctly.