class__dummyInstance not called properly

[romainfrancois]

Spotted here.

The problem is that here it is called with quotes when it should not.

new_dummyObject <- function(...)
    .External( "class__dummyInstance", ...)

[justacec]

I have just tried to install this latest version on a Windows 2008 Server platform and am receiving the same original error:

> library(Rcpp)
Error : .onLoad failed in load Namespace() for 'Rcpp', details:
  call: new_dummyObject(.dummyInstancePointer)
  error: object 'class__dummyInstance' not found
In addition: Warning message:
pakcage 'Rcpp' was built under R version 3.0.3
Error: package or namespace load failed for 'Rcpp'

The system that I am trying to load the package is Windows Server 2008R2 running R 3.0.2

To get to this point I used the following procedure:

1. Downloaded the most recent master code from Github (Should be commit 5b510ed)
2. Uncompressed the zip file in a temporary directory and rename 'Rcpp-master' to 'Rcpp'
3. Installed Rtools version 3.1
4. Ensured that RTools bin and the related gcc bin directory was at the beginning of my path
5. Used the command "R CMD BUILD Rcpp" to generate the Rcpp_0.11.1.2.tar.gz file
6. Use the command "R CMD INSTALL --build --compile-both Rcpp_0.11.1.2.tar.gz to generate the Rcpp_0.11.1.2.zip
7. Used the R native install local package to install the Rcpp package

*Note: The machine I built the package on was Win7. I copied the resulting file from step 6 to a different machine to do the install in step 7.

Any help on this issue will be greatly appreciated as it is causing work stoppage with the latest version of ggplot2 as this is a 2nd order dependency.

[justacec]

An additional follow-up for the above comment is the the package loads fine on R 3.0.1 and R 3.0.3 on Microsoft Windows Server 2003 R2 with Service Pack 2.

[eddelbuettel]

There is some disconnect between you saying Windows Server 2008R2 running R 3.0.2 and R reporting pakcage[sic!] "Rcpp" was built under R version 3.0.3.

Your procedure looks spot on. But maybe you now have several versions of Rcpp installed, and still load the wrong one? Try to see what .libPaths() returns, and check those directories.

[eddelbuettel]

Moreover, Rcpp from CRAN loads and starts fine on my (essentiallty unused as work on Linux) Windows installation of R 3.0.2.

[justacec]

It is true that I compiled the package on a machine that was running R version 3.0.3 and am now trying to use it on an R 3.0.2 install which would be the source of the warning message. I get this message all the time from packages that I download from the CRAN and it has posed no real issues.

As for the .libPaths() question... There are two returned paths:

[1] "\\\\vnxserver/home/MYACCT/My Documents/R/win-library/3.0"
[2] "C:/Program Files/R/R-3.0.2/library"

I checked each of these two locations and only the most recent install of Rcpp is in location 1.

[justacec]

"Moreover, Rcpp from CRAN loads and starts fine on my (essentiallty unused as work on Linux) Windows installation of R 3.0.2."

Yes, this problem seems to be linked to execution on the Windows Server 2008 platform for some reason...

[eddelbuettel]

I suspect something local.

CRAN builds and rebuilds everything on Windows too when we make releases, and would have us in no uncertain terms if there was an issue.

So with that I don't have a good avenue for you in terms of how to squash this...

[justacec]

I have re-posted this error on [SO][1] in the hopes that some might have suggestions on possible debugging steps.

[1] http://stackoverflow.com/questions/23917188/unable-to-load-the-rcpp-package-in-windows-server-2008

[eddelbuettel]

I think you have to necessary ingredients (R, Rtools, the system on which it breaks, ...) whereas the typical SO reader does not. I'd also add the 'rcpp' tag over there...

In any event, the most official place for support is the rcpp-devel list. If you get nowhere on SO, consider posting there.

[justacec]

Post amended as suggested...

[eddelbuettel]

Thanks, I missed the link at fist and then saw it (and removed my comment). Being more explicit is better.

[justacec]

Problem was determined to be a security implementation that did not allow for dll files to be opened from users home directories. We corrected the problem by creating a special location on the system that was allowed to load dlls for specific users.

Problem solved...

I think that R could have done a better job here in notifying me that the dll file did not load completely. The only way to know is to try to list the symbols in the library and then see that there are none.

[eddelbuettel]

Thanks for following up. You could raise the issue on the r-devel list but as this is an OS-specific issue it is tricky to get to it from application-space.