Dealing with R 4.0

@torkar: But does Stan work?

Yes, except for when using cores=4, but that’s an RStudio bug which there’s a workaround for :)

Daniel - I don’t know if you have solved this problem already, but since I came across your post when looking for a solution to exactly the same issue, I thought I’d share what worked for me: putting the following in your Makevars file. Hope it solves your problem.

CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

1 Like

bumping thread

bumping again

You can probably ask @martinmodrak to pin it!

There’s a lot of results when googling which seem to deal with the OSX side of the issue. I don’t use OSX but the underlying issues is described at https://github.com/Andersbakken/rtags/issues/937#issuecomment-293459813 and https://github.com/cbcrg/tcoffee/issues/7#issuecomment-626081446 .

The issue is that somehow a math.h is ending up in the compiler search path before the C++ math.h. The solution will be to avoid this.

An example of how this can happen is if you include say, glibc before the c++ stdlib.

Hi,
I’ve installed R-4.0.0 and R-3.6.3 on Linux-Ubuntu 20.04 following the guide:
https://docs.rstudio.com/resources/install-r/
Where I changed the curl download from ubuntu-1604 to ubuntu-2004. I can start both within Rstudio and with R-4.0.0 in Rstudio I ran the advised code in OP but ended up installing some extra packages with the Terminal in order to get shinystan to work. Rstan works indeed, thank you!

Question: If i now start R-3.6.3 in Rstudio and run install.packages(‘rstan’, dependencies = TRUE) again, would you expect any complications? It is ok if Rstan just works in R4.0.0, but I could work more flexible if it works in multiple versions. However I am hesitant to just try it and risk breaking what is currently working.

On linux, you should be okay back to R 3.4.x and even previous versions if your C++ compiler supports the C++14 standard (although you may have to adjust the required version of R in the DESCRIPTION file).

That was wonderful Ben. Works like a charm, thank you for sharing!

Is this installation guide (install.txt) somewhere online? I found it very good and the official Rstan getting started does not seem to have this info about R 4.0.0 problems.

It’s not, no. It was just a document I sent to some students/faculty prior to a Stan seminar. I wouldn’t mind if the Stan team wanted to use it somewhere though.

1 Like

I can update RStan’s getting started guide with this info. I’ll have a first run at adding this in and ping you for a quick review to see if I’ve missed anything (if that’s ok).

@bgoodri Any preference on whether this goes into the ‘RStan Getting Started’ page or gets added as separate ‘RStan & R4.0’ page?

3 Likes

I think I have a more updated one: install.txt (783.5 KB)

The main story though - Is the pre-R4.0 instructions should be fine on < 4.0 setups. After R 4.0, Rtools40 should be used on windows, and Xcode (only) should be used on osx. Any previous configurations should be stripped out (in .Rprofile, .Renviron, and R/Makevars{.win}). They can be recreated with optimization options only (and the Rstudio parallel fix for OSX); no need for paths.

2 Likes

@Stephen_Martin, would it be possible to provide some optimization options for default compilers in Win/Lin/OS X, so new people simply can cut and paste into their Makevars?

I’ll add another tabbed section for ‘what the files should contain’ after R 4.0. It’ll have a section for the compiler optimizations, and another for the (current) Rstudio osx parallel bug.

1 Like

Oh, another thing: Is there a particular reason why uploading html files is not allowed here? I think it’d be useful, not only for this, but because jupyter and knitr html outputs are common enough filetypes for this community. I’d think that html upload would be useful.

This probably deserves its own thread to properly discuss, but the short answer is that the Discourse default is to not allow most file types for security reasons. We can definitely customize that and enable additional file types, but I don’t personally know if enabling html would actually present any security risks (seems possible but unlikely, but not my area of expertise!). I definitely agree it would be a very useful format to allow though.

1 Like

I think we need both 4.0 and a 3.x instructions but 4.0 is recommended.