We have added a mounted /opt/R file share on our RHEL box to allow for multiple version of R for RStudio Server Pro. We also installed them as a service account so they not owned by root and can be centrally accessed.
Using the standard ./congfigure, make install commands results in a version of R being created in this folder, but two odd things happen:
The platform R is configured against is generic (x86_64-pc-linux-gnu (64-bit)). Our server's version of R is compiled against RHEL (x86_64-redhat-linux-gnu (64-bit)). I have been unable to find any documentation that explains this issue. The consequence is that all packages have to be re-downloaded if this version is used.
The capabilities() command shows the compiled version of R is lacking many of the standard features the system version has. For instance, jpeg, png, and cairo are all missing. This is not the case for the system version where all those items are available.
Good questions! Do you mind clarifying what you mean by platform R? Are you talking about the binary that is downloaded with yum install R, or something to that effect?
On (2), capabilities are a function of your ./configure command and the dependent system libraries that you have available. At the end of your ./configure output, you will see a premonition of what capabilities are skipped / available. The easiest way to create a "mostly-full-featured" R install (has most/all capabilities) is to execute yum-builddep R (which downloads all build dependencies on a RHEL machine) and then use the ./configure command we illustrate in the RStudio Connect documentation:
Thanks for the quick response. Yes, I am talking about the binary installed through yum.
I have not run yum-builddep R because we have restricted sudoer access. I can have that run, but I'm not sure how it would make a difference. If the RHEL binary recognizes that png, jpeg, and cairo exist, why doesn't the source-compiled version?
We ran into a similar issue when building some older versions R, where the configure script guessing would come up with "unknown" instead of "pc". We worked around it by supplying --build=x86_64-pc-linux-gnu when running configure.
R is now configured for x86_64-redhat-linux-gnu
Source directory: .
Installation directory: /opt/R/3.4.1
C compiler: gcc -std=gnu99 -g -O2
Fortran 77 compiler: gfortran -g -O2
Default C++ compiler: g++ -g -O2
C++98 compiler: g++ -g -O2
C++11 compiler: g++ -std=gnu++11 -g -O2
C++14 compiler:
C++17 compiler:
Fortran 90/95 compiler: gfortran -g -O2
Obj-C compiler:
Interfaces supported: X11, tcltk
External libraries: readline, curl
Additional capabilities: PNG, JPEG, NLS, ICU
Options enabled: shared R library, shared BLAS, R profiling, memory profiling
Capabilities skipped: TIFF, cairo
Options not enabled:
Recommended packages: yes
Then I ran make install which successfully completes. When I navigate to that specific version of R using:
/opt/R/3.4.1/lib64/R/bin/R
This is what I see:
R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
>
Notice that platform is x64_64-pc-linux-gnu (64-bit) even though the specified build is against redhat. When I run the capabilties() command, this is what I see:
Very strange! Did you have R installed in that location previously? Although annoying, I find the safest way to run builds is to make a clean tar -xzvf of the source bundle (i.e. purge the previous extraction) and then build to a clean --prefix (i.e. destroy everything ahead-of-time, rm -r /opt/R/3.4.1, etc.).
This is mostly because I have seen hold-overs of random options from previous builds (if I try to install over top of an existing installation), and I don't want to do the digging to find out why / what is sticking around.
I removed the compiled and untarred source directories, untarred the source R version, recompiled with the options above and installed. Here's the configure output:
R is now configured for x86_64-redhat-linux-gnu
Source directory: .
Installation directory: /opt/R/3.4.1
C compiler: gcc -std=gnu99 -g -O2
Fortran 77 compiler: gfortran -g -O2
Default C++ compiler: g++ -g -O2
C++98 compiler: g++ -g -O2
C++11 compiler: g++ -std=gnu++11 -g -O2
C++14 compiler:
C++17 compiler:
Fortran 90/95 compiler: gfortran -g -O2
Obj-C compiler:
Interfaces supported: X11, tcltk
External libraries: readline, curl
Additional capabilities: PNG, JPEG, NLS, ICU
Options enabled: shared R library, shared BLAS, R profiling, memory profiling
Capabilities skipped: TIFF, cairo
Options not enabled:
Recommended packages: yes
configure: WARNING: neither inconsolata.sty nor zi4.sty found: PDF vignettes and package manuals will not be rendered optimally
I performed the make and make install, then open R using:
3.4.1/lib64/R/bin/R
Here's what I see when I open it:
R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-redhat-linux-gnu (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
>
It now appears that it's compiled against redhat instead of the generic linux version. This is what I get when I run capabilities():
Now I'm more confused. It properly compiled against redhat, recognized the png, jpeg libraries, but still doesn't show up as a capability? Could this be a java issue (Using 1.8.0_144)?
I would not expect it to be a Java issue. As Josh recommended, the full config.log would be helpful. Usually it has notes in there about the capabilities that were added, what libraries were found, etc.
In particular, it would be helpful to know what your system dependencies look like, too. Not sure how effective this will be as non-root, but maybe useful?
# the full output of system packages that are installed
[test@8c71216d47dd /]$ yum list installed
...
# focusing on one
[test@8c71216d47dd /]$ yum list installed | grep 'jpeg'
ovl: Error while doing RPMdb copy-up:
[Errno 13] Permission denied: '/var/lib/rpm/Sha1header'
libjpeg-turbo.x86_64 1.2.90-5.el7 @base
libjpeg-turbo-devel.x86_64 1.2.90-5.el7 @base
openjpeg-libs.x86_64 1.5.1-17.el7 @base
Did you recompile R? It seems like you just set LD_LIBRARY_PATH for the existing R installation. I'm not sure whether capabilities can be changed after-the-fact by changing LD_LIBRARY_PATH, but I am definitely out of my depth here.
To be thorough, you could also check Sys.getenv("LD_LIBRARY_PATH") inside of the R install. You could even try system("ldd /path/to/R_X11.so") from inside the R install too, to make sure startup is not causing problems.
This is still a WIP. We were able to get it working properly on a separate VM where R was NOT installed via YUM. It seems like once you YUM install any R version, compiling from source will try to reference prebuilt binaries. I suspect that environmental variables are an issue but it’s unclear which ones should be purged or changed. Any advice would be great.
In the meantime, we’re trying to figure out a work around for our production development environment.
Finally have a solution! As @cole alluded to, the compilation of R in the /opt/R folder is referencing libraries for the system installed version of R. When it compiles, there's a version mismatch that causes the issues with JPEG, PNG, TIFF, and Cairo. We tried changing environmental variables, but that didn't fix the problem.
The solution was to uninstall the system version of R and purge all it's dependencies (R-core, R-java, etc). We then installed source versions of R in the /opt/R folder. This solved the problem and now we have multiple R versions available.
If you are willing to consider Microsofts' builds of R (MRO), it is very easy to have more than one version on the system. Just download the tar files from mran.microsoft.com, extract the rpms, then install them with --noscripts and --prefix options. After that you can symlink the installs to /opt/R:
The same approach works with other versions of MRO. I think we have 4 different versions on our RStudio Pro server. Unless you need highly customized builds of R that approach works very well.
Thanks @alexv. I think that is something we will explore as we build a process around deploying multiple R versions.
One final twist on this project was that once we compiled from source and removed the system R, images failed to be produced on Connect. Long story short, in RHEL, R will try to use X11 to generate graphics instead of Cario no matter what your compilation arguments are (we tried --without-x and the issue persisted).
The solution is to either yum install pango-devel OR edit your /etc/rprofile.site file and insert this option:
options(bitmapType='cairo')
This forces R to use Cairo no matter how the R version is compiled. I haven't tested it, but I suspect this same problem would exist using MRAN builds.