Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

R CMD build issue on Windows with R 4.2 #73

Closed
jlmelville opened this issue Jul 2, 2022 · 9 comments
Closed

R CMD build issue on Windows with R 4.2 #73

jlmelville opened this issue Jul 2, 2022 · 9 comments

Comments

@jlmelville
Copy link
Contributor

I am having problems building the latest checkout of master on Windows with R 4.2.1:

E:\dev\R>"C:\Program Files\R\R-4.2.1\bin\R.exe" CMD build rcppannoy-gh
* checking for file 'rcppannoy-gh/DESCRIPTION' ... OK
* preparing 'RcppAnnoy':
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
      -----------------------------------
* installing *source* package 'RcppAnnoy' ...
** using staged installation
** libs
g++  -std=gnu++11 -I"C:/PROGRA~1/R/R-42~1.1/include" -DNDEBUG -I../inst/include/  -I'E:/dev/R/win-library/4.0/Rcpp/include'   -I"C:/rtools42/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c RcppExports.cpp -o RcppExports.o
g++  -std=gnu++11 -I"C:/PROGRA~1/R/R-42~1.1/include" -DNDEBUG -I../inst/include/  -I'E:/dev/R/win-library/4.0/Rcpp/include'   -I"C:/rtools42/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c annoy.cpp -o annoy.o
g++  -std=gnu++11 -I"C:/PROGRA~1/R/R-42~1.1/include" -DNDEBUG -I../inst/include/  -I'E:/dev/R/win-library/4.0/Rcpp/include'   -I"C:/rtools42/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c arch.cpp -o arch.o
gcc  -I"C:/PROGRA~1/R/R-42~1.1/include" -DNDEBUG -I../inst/include/  -I'E:/dev/R/win-library/4.0/Rcpp/include'   -I"C:/rtools42/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -std=gnu99 -mfpmath=sse -msse2 -mstackrealign  -c init.c -o init.o
g++  -std=gnu++11 -I"C:/PROGRA~1/R/R-42~1.1/include" -DNDEBUG -I../inst/include/  -I'E:/dev/R/win-library/4.0/Rcpp/include'   -I"C:/rtools42/x86_64-w64-mingw32.static.posix/include"     -O2 -Wall  -mfpmath=sse -msse2 -mstackrealign  -c version.cpp -o version.o
g++ -shared -s -static-libgcc -o RcppAnnoy.dll tmp.def RcppExports.o annoy.o arch.o init.o version.o -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -LC:/PROGRA~1/R/R-42~1.1/bin/x64 -lR
installing to C:/Users/jlmel/AppData/Local/Temp/RtmpOOV4HF/Rinst720470b2363b/00LOCK-RcppAnnoy/00new/RcppAnnoy/libs/x64
** R
** demo
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
ERROR: loading failed
* removing 'C:/Users/jlmel/AppData/Local/Temp/RtmpOOV4HF/Rinst720470b2363b/RcppAnnoy'
      -----------------------------------
ERROR: package installation failed

I get the same error with the latest R-devel. Using R-4.1.3 works. I have tried reinstalling rtools42 which had no effect.

I would chalk this up to something misconfigured with my local machine except I have forked this repo and added a github action to build against the latest and previous Windows builds and get the same result: windows-latest (release) is failing due RcppAnnoy not building and windows-latest (oldrel) succeeds.

In addition, my package RcppHNSW (which is modeled closely off RcppAnnoy) also shows the same problem, which suggests there is something going on here.

I can build other projects that use Rcpp without issues. So far RcppHNSW and RcppAnnoy are the only ones that I have found that are failing. A difference I have noted is that they both wrap C++ classes using RCPP_EXPOSED_CLASS_NODECL, RCPP_MODULE and Rcpp::class where other projects I have built do not.

I am not quite sure where to start on this (maybe try to reproduce the issue by wrapping a minimal C++ class?). Any pointers or tips would be helpful to me.

@eddelbuettel
Copy link
Owner

As much as I would like to, I simply cannot help you: this is not reproducible, and it does not even show an error. All we have is 'no soup for you' in "ERROR: loading failed'.

Both RcppAnnoy and RcppHNSW are fine at CRAN:

(apart from notes about size, and in your case also about LazyData).

More importantly it builds and checks on three different Windows setups. Have you tried submitting to win-builder to cross-check? Also maybe this is an issue with GH Actions setup?

@jlmelville
Copy link
Contributor Author

I saw CRAN checks are passing so I hesitated to raise this issue further, but it isn't clear to me from those pages if the package is being built every day vs checked. That's on me for not having looked into it further.

My understanding of winbuilder is that you upload the result of running R CMD build, but that is the step which fails with no output for me. For the record, this is failing for me on both the github actions and when I run R CMD build directly on my own laptop, so it would have to be an issue with my machine and GH actions.

But anyway, I see I may have some more research to do. I appreciate how busy you are so thank you for taking a look.

@eddelbuettel
Copy link
Owner

I understand how frustrating this can be. I think I would start with baselines: call Rcpp.package.skeleton("throwawaypackage") and see if that builds. If so, make it 'bigger' and closer to your real package, ideally in small steps. If not, you know your package is not at fault (good) but your installation may be (uggh).

@jlmelville
Copy link
Contributor Author

A minor update: I built the source tarball via R CMD build on Linux via WSL using exactly the same checkout of the source code that fails under Windows 10 itself, and uploaded to win-builder. No errors were reported. Can't argue with that.

A skeletal Rcpp project attempt to wrap a class that adds two ints also fails for me locally. The call to Rcpp::loadModule to load the wrapped class is involved in crashing the session, as commenting that out prevents the crash.

Finally, I note that as well as my laptop, and GitHub actions, Appveyor is also failing to build both RcppHNSW and my fork of RcppAnnoy (the fork adds no code except to include the CI files). That's three separate environments that no longer work ( changes to do with UCRT?), but oh well. My solution may be to move to doing development on Linux only and relying entirely on winbuilder going forward.

@eddelbuettel
Copy link
Owner

Glad to hear you are up and running but very confused about the failures. We build the package for my day job in CI under all three OSs and have not had issues, not have I heard from anyone else. Rcpp Modules is also not that rare, and I have not heard from other failures. Very odd -- strictly no active suspicion from my end.

@jlmelville
Copy link
Contributor Author

I should probably just let this issue sink without trace, but I will confess my sin: I must have failed to correctly rebuild a library between 4.1 and 4.2. Don't know what was the exact problem because I took the nuclear option of a complete deletion of everything. Sorry for the confusion. Wish I knew why the CI fails though (as it doesn't seem to be building any dependencies from source).

@eddelbuettel
Copy link
Owner

It happens. The ABI/API issues are real, and they are worth on some systems relative to others.

So to recap: do you still have issues on CI, and if so, which platform?

@jlmelville
Copy link
Contributor Author

So to recap: do you still have issues on CI, and if so, which platform?

With github actions Windows Server 2022 with R 4.2 (but R 4.1 is ok). Also on appveyor using Windows Server 2012 with R 4.2. Linux and Mac succeed.

But perhaps there are some caching issues with those Windows CI runs (not obviously the case from the output unfortunately)?

@eddelbuettel
Copy link
Owner

Yes, could possibly be caching issues. I don't use the actions as I find them too opaque / hard to debug.

I believe you can force a cache rebuild but it being Windows you may still get binaries and if your hunch is right maybe those are wrong -- no idea, sorry. As I said earlier, works elsewhere and works at CRAN so tough one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants