Error in compileCode for r package using rstan

Hi all, I’m working on an R package that uses rstan for estimation. When I ran the devtools::check_rhub() to check the package, I encountered the error specific to rstan on Windows that can be fixed by making changes to the local computers (…)

make -f "C:/PROGRA~1/R/R-devel/etc/x64/Makeconf" -f "C:/PROGRA~1/R/R-devel/share/make/" -f "C:\Users\USERozsLrYfilk/.R/Makevars.win64" CXX='$(CXX14) $(CXX14STD)' CXXFLAGS='$(CXX14FLAGS)' CXXPICFLAGS='$(CXX14PICFLAGS)' SHLIB_LDFLAGS='$(SHLIB_CXX14LDFLAGS)' SHLIB_LD='$(SHLIB_CXX14LD)' SHLIB="file1804377c331b.dll" WIN=64 TCLBIN=64 OBJECTS="file1804377c331b.o"

 807#> make would use

 808#> if test "zfile1804377c331b.o" != "z"; then \

 809#> if test -e "file1804377c331b-win.def"; then \

 810#> echo "C:/rtools40/mingw64/bin/"g++ -shared -s -static-libgcc -o file1804377c331b.dll file1804377c331b-win.def file1804377c331b.o -L"c:/R/local330/lib/x64" -L"c:/R/local330/lib" -L"C:/PROGRA~1/R/R-devel/bin/x64" -lR ; \

 811#> "C:/rtools40/mingw64/bin/"g++ -shared -s -static-libgcc -o file1804377c331b.dll file1804377c331b-win.def file1804377c331b.o -L"c:/R/local330/lib/x64" -L"c:/R/local330/lib" -L"C:/PROGRA~1/R/R-devel/bin/x64" -lR ; \

 812#> else \

 813#> echo EXPORTS > tmp.def; \

 814#> "C:/rtools40/mingw64/bin/"nm file1804377c331b.o | sed -n 's/^.* [BCDRT] / /p' | sed -e '/[.]refptr[.]/d' -e '/[.]weak[.]/d' | sed 's/[^ ][^ ]*/"&"/g' >> tmp.def; \

 815#> echo "C:/rtools40/mingw64/bin/"g++ -shared -s -static-libgcc -o file1804377c331b.dll tmp.def file1804377c331b.o -L"c:/R/local330/lib/x64" -L"c:/R/local330/lib" -L"C:/PROGRA~1/R/R-devel/bin/x64" -lR ; \

 816#> "C:/rtools40/mingw64/bin/"g++ -shared -s -static-libgcc -o file1804377c331b.dll tmp.def file1804377c331b.o -L"c:/R/local330/lib/x64" -L"c:/R/local330/lib" -L"C:/PROGRA~1/R/R-devel/bin/x64" -lR ; \

 817#> rm -f tmp.def; \

 818#> fi \

 819#> fi

 820#> C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: file1804377c331b.o:file1804377c331b.cpp:(.text$_ZN3tbb8internal26task_scheduler_observer_v3D1Ev[_ZN3tbb8internal26task_scheduler_observer_v3D1Ev]+0x14): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: file1804377c331b.o:file1804377c331b.cpp:(.text$_ZN3tbb8internal26task_scheduler_observer_v3D0Ev[_ZN3tbb8internal26task_scheduler_observer_v3D0Ev]+0x1c): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: file1804377c331b.o:file1804377c331b.cpp:(.text$_ZN4stan4math16ad_tape_observerD1Ev[_ZN4stan4math16ad_tape_observerD1Ev]+0x15): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'C:/rto

 821#> Calls: ... -> -> force -> cxxfunction -> compileCode

 822#> Error in sink(type = "output") : invalid connection

 823#> Calls:  ... -> stan_model -> cxxfunctionplus -> sink

 824#> Execution halted

 825#> Error in compileCode(f, code, language = language, verbose = verbose) :

but when I ran the check_win_devel, there was no error. And also when I used “dontrun” for my examples in the documentation, there was no error, but CRAN requires the change from “dontrun” to “donttest”, and now I’m using “donttest”, the error occurs. Any suggestions about how to fix the error in the r package to make it work on Windows? Thanks!


In my experience if it passes on wid_devel it should be fine. Rhub can be a bit flaky and have the wrong package versions etc.

Also, do you have a link to the package? It might help to diagnose the problem.


1 Like

After I unwrapped my examples in the documentation as requested by CRAN reviewers, it fails to pass win_devel as well…and here is the link to my package: GitHub - Naidantu/bmggum: bmggum R package. It works well on Mac.

I have good news and bad news:

The bad news is that in it’s current form your package won’t work on windows at all.

The good news is that if you switch to the package structure produced by rstantools then it will!

It may help to check out rater an R package using rstan on CRAN which I maintain.


1 Like

The only difference I saw between the package structure of the rater package and the structure of my package is that there are some additional files in the rater package (e.g.,, is it the addition of these files that make the packages depending on rtsan work on Windows? If yes, would simply manually adding these files to my package work?

There are other differences too: the stan code is in files in the inst directory and there is custom code in stanmodels.R to compile and load the models.

It will require a bit of refactoring for you but using rstantools is the only way to reliably get an rstan based package onto CRAN.



Thanks for the help. Another question: do I have to completely ditch my current package folder and use the rstantools to create a new package or I can first use it to create a new package and move the files in the new package to my current package folder and then refactor the code based on the instructions since my current package folder is connected to github and other things.

1 Like

I’m not sure. Personally, I would probably create a new package structure and then copy/refactor it across into your existing directory.

Ok, thanks. I’ll try it first.

Hi Jeffrey, I’ve refactored my package and I received the following NOTES when I ran devtools::check(). Do I need to fix them before CRAN submission? The first NOTE reg the package size seems to be related to the files in the src folder, especially the .so file. Is it ok to delete the files in the src folder? Thanks.

> checking installed package size ... NOTE
    installed size is  7.6Mb
    sub-directories of 1Mb or more:
      libs   7.1Mb

> checking for GNU extensions in Makefiles ... NOTE
  GNU make is a SystemRequirements.
1 Like

You can safely ignore those two notes.

*.cpp and *.o files should be not be in the git repository i.e. you should include them in you .gitignore. (You will still see the first note though)