Building RCall with R >= 3.5.0

[drjdn]

I'm on an x86-64 linux system running Manjaro. RCall fails to build when using R >= 3.5.0. It basically hard freezes and I have to kill the terminal. This holds true with julia 0.6.4, 0.7 and 1.0. On the same system it will build fine using R 3.4.4 (julia 0.6.4, 0.7 and 1.0). Also, if I build RCall with R 3.4.4 and then switch to R 3.5.1 it seems to work properly. If I kill my .julia directory and try to reinstall RCall it exhibits the same freezing behaviour.

Thanks, Jason

[randy3k]

if I build RCall with R 3.4.4 and then switch to R 3.5.1

Did you run Pkg.build("RCall") in this case?

Would you also report the console output where it freezes?

[drjdn]

No, I have R-3.4.4 and R-3.5.1 built and use /usr/local/R as the prefix of the build. So I can just change the symlink (or just copy over either to /usr/local/R). I can build RCall with R-3.4.4 and then switch over to R-3.5.1 and it will run correctly (an R.version call in the R prompt under julia confirms the correct build). If I Pkg.build("RCall") when running R-3.5.1 it will freeze the terminal again. By freeze, I don't mean my system, just the terminal. None of ^C, ^D or ^Z do anything and the only thing I can do is kill the term. Nothing is happening when it freezes as all CPUs are at zero usage.

The last few lines when it freezes are:

  Building CodecZlib → `~/.julia/packages/CodecZlib/wwgbh/deps/build.log`
  Building Conda ────→ `~/.julia/packages/Conda/m7vem/deps/build.log`
  Building RCall ────→ `~/.julia/packages/RCall/Q4n8R/deps/build.log`

Thanks, Jason

[randy3k]

I guess it is because RCall got confused when you have two versions of R. Would you try specifying the R_HOME rather than the symlink? R RHOMEin terminal or R.home() in R should tell you the value of R_HOME.

ENV["R_HOME"]="path to R 3.5.1"
Pkg.build("RCall")

[drjdn]

No, it doesn't matter. In both cases:

bash#  echo $R_HOME
"/usr/local/R/lib64/R"

I'm not using two versions of R at the same time. Only one is in the PATH and LD_LIBRARY_PATH which would be $R_HOME/bin and $R_HOME/lib respectively. The symlink doesn't matter. I can also just copy them over to /usr/local/R and the same behaviour occurs.

Thanks, Jason

[randy3k]

Just to make sure R_HOME points to a right location. Could you report (with R 3.4) the followings

using RCall
RCall.Rhome
RCall.libR

[randy3k]

But you even got stuck with an empty .julia directory, I really have no ideas why....

[drjdn]

Here is the output with R 3.4.4

julia> using RCall

julia> RCall.Rhome
"/usr/local/R/lib64/R"

julia> RCall.libR
"/usr/local/R/lib64/R/lib/libR.so"

R> R.version
               _                           
platform       x86_64-pc-linux-gnu         
arch           x86_64                      
os             linux-gnu                   
system         x86_64, linux-gnu           
status                                     
major          3                           
minor          4.4                         
year           2018                        
month          03                          
day            15                          
svn rev        74408                       
language       R                           
version.string R version 3.4.4 (2018-03-15)
nickname       Someone to Lean On  

and with R 3.5.1 without the Pkg.build step:

julia> using RCall

julia> RCall.Rhome
"/usr/local/R/lib64/R"

julia> RCall.libR
"/usr/local/R/lib64/R/lib/libR.so"

R> R.version
               _                           
platform       x86_64-pc-linux-gnu         
arch           x86_64                      
os             linux-gnu                   
system         x86_64, linux-gnu           
status                                     
major          3                           
minor          5.1                         
year           2018                        
month          07                          
day            02                          
svn rev        74947                       
language       R                           
version.string R version 3.5.1 (2018-07-02)
nickname       Feather Spray

[randy3k]

How about trying the R via conda?

ENV["R_HOME"]="*"
Pkg.build("RCall")

[drjdn]

That works. It also seems that conda is running R 3.5.0 so that debunks my R >= 3.5.0 theory. Do you use conda regularly? I'd be interested in knowing what flags they use to build R.

Still strange to me as I built R-3.4.4 and R-3.5.1 from source using the same flags. One works and the other doesn't on the same system using the same julia with a clean .julia.

Jason

[drjdn]

Out of curiosity I built R 3.5.0 using the same flags and build prefix. It works! So this seems to be a R > 3.5.0 issue. For the record I killed .julia so the previous conda success is not a factor.

Jason

[randy3k]

For the record, R 3.5.1 works in my macOS.

[drjdn]

OK. Feel free to close this then as there is no way I can sort this out. Did you build R 3.5.1 from source or just use a binary on OSX? I'm on a system using gcc 8.2 and most tools are the most recent stable versions. That said, it doesn't account for the fact that I can build RCall with R-3.4.4 and R-3.5.0 and have no issues but with R-3.5.1 it is a problem (all build parameters and tools the same). This is true whether I'm using julia 0.6.4, 0.7.0 or 1.0.0.

[randy3k]

I am using the R from CRAN though. I don't expect anything would break on R 3.5.1 and there is no reason to break. Btw, is there anything in build.log?

[drjdn]

I'm afraid not, that was the first thing I checked. It really does hard freeze the terminal making diagnostics difficult. Conda works but that isn't really a solution for me. For the moment I build RCall with R 3.4.4 and then switch over to R 3.5.1 (keeping .julia as is) as that gives me a working solution.

When I have some spare time I'll try building R 3.5.1 with default configuration and see if that works. I used the same config to build 3.4.4 though so I'm pretty sure it is something else that is causing the issue. I have a pretty up to date system so that might have something to do with it but if that was the case I'd expect failure across the board.