I had some issues when I recently started building ROOT with the current release of the R statistics package version 4.0.0, i.e. when trying to build ROOTR.
After successful compilation and installation of R-4.0.0, I followed the instructions of the ROOTR Users Guide and build ROOT with R. Configuring the project using CMake and setting the flag for building ROOTR (-Dr=ON) seemed to work, as the output indicated R was found along with the required additional libraries (RInside, Rcpp). Although every further step including installation and running the included tests seemed successful, any attempt at running any of the R tutorials failed with the error message that the necessary R libraries (RInside, Rcpp) could not be found.
Checking my R installation showed that the necessary libraries were indeed present. I finally checked the CMakeCache.txt of my ROOT project and found that there was no value listed for R_Rcpp_LIBRARY, although the “include”-directory had been correctly identified.
In total, two issues seem to cause problems when trying to build ROOTR:
The Rcpp library is not located in the subdirectory “lib” as expected, but rather in “libs”, such that CMake does not find it as the “lib” directory seems to be the only directory searched and set regardless of Rcpp.so location.
CMake can be forced to find this directory/library by setting -DR_Rcpp_LIBRARY=<path-to-R-libraries>/Rcpp/libs/Rcpp.so. Considering the point made below, the flag actually needs to be set to -DR_Rcpp_LIBRARY=<path-to-R-libraries>/Rcpp/libs/libRcpp.so.
Then the build still fails at link time, as the linker flag set for Rcpp is “-lRcpp”, such that it tries to link against libRcpp.so. Unfortunately, the “lib”-prefix is not used for this R package, so the build fails upon trying to link against a seemingly missing library. A possible solution would be to set the linker flag to -l:Rcpp.so, but I was not able to quickly figure out how to do that correctly.
Setting a symbolic link (ln -s <path-to-R-libraries>/Rcpp/libs/Rcpp.so <path-to-R-libraries>/Rcpp/libs/libRcpp.so) solves this problem, and ROOT can be successfully built including ROOTR. However, this solution seems quite crude to me.
For clarification, my R libraries are located in $R_HOME/library (R installation directory depending on chosen (or default) prefix), and that is what <path-to-R-libraries> refers to in the above.
The two steps above suffice to get ROOTR to build such that the R tutorials can successfully be run. I hope that anyone trying to use R statistics within ROOT might find the above helpful.
It seems that these issues could be avoided if correctly handled in the CMake process set up for the ROOT project. This should also include a check for the actual presence of the required R libraries which seems to be missing currently. Unfortunately I am no expert on this, such that I am unable to propose a fix. Maybe this issue seems worth investigating to the ROOT developers.
I might be able to provide a quick independent test with a new build should a fix become available. Just for information, the issue I described in my original post is independent of R version used - same causes and fixes apply to the two latest releases of R (3.6.3. and 4.0.0). I originally thought the issue it might be related to using a release of R newer than the current ROOT release, but that does not seem to matter, i.e. it is not the problem’s source.
This is Ubuntu 20.04 LTS / x86_64 / gcc 9.3.0 with the system provided R 3.6.3 here.
I have no problems in enabling and building the “r” feature for the ROOT 6.20/04 tag and the “v6-20-00-patches” branch.
After (successfully) testing the new ROOT build and quickly checking ROOTR by running some of the tutorials provided (works fine), I came across another rather peculiar behavior:
Executing ROOT from the bin directory of the build tree leads to ROOTR working without any issues. Here gSystem->ListLibraries() shows 40 libraries loaded, among these libR.so, libRcpp.so, libRInside.so and libRInterface.so.6.20.04.
However, installing ROOT and then executing it from the installation directory results in ROOT running as expected and wanted, but in ROOTR failing, as the necessary includes and libraries apparently cannot be found and loaded, despite sourcing thisroot.sh from the installation directory before executing ROOT.
Here gSystem->ListLibraries() shows 18 libraries loaded, and libR.so, libRcpp.so, libRInside.so and libRInterface.so.6.20.04 are among the missing ones.
Errors e.g. when issuing #include<TRInterface.h> at the ROOT prompt are:
cling::DynamicLibraryManager::loadLibrary(): libRcpp.so: cannot open shared object file: No such file or directory
Error in TInterpreter::TCling::AutoLoad: failure loading library libRInterface.so for TRInterface.h
and so on…
The only difference between ROOTR working as expected or failing is the installation step from the ROOT build tree to the installation directory in /usr/local. I am stunned, and I am lacking ideas how to fix this myself. I suppose this is caused by some missing configuration information that is lost (or rather not correctly copied or transferred) during installation.
Any ideas or suggestions how to fix this (hopefully last) remaining problem are highly welcome.
have you actually tested running an R tutorial/example while running ROOT both within your build tree and after its installation to an install prefix? I am wondering if this works on your system.
By the way, enabling and building the “r” feature always looked successful on my system, but running code using R it did not.
Well, then this behavior is consistent with the content of my follow-up post. After my successful build, it works perfectly on my machine, albeit only directly from the “<builddir>”.
That aside, for the past 15 years, I have always been installing ROOT in user-defined locations, i.e. under /usr/local/root-<version #>.
Nonetheless, I am still looking for a solution when installing ROOT into another system location…
@Axel Out of curiosity, I executed in the "<builddir>”: cmake -DCMAKE_INSTALL_PREFIX=/tmp/root -P cmake_install.cmake
and then I found that three libraries in “ROOTSYS=/tmp/root” are broken.
report: libRInside.so => not found
while for the same libraries in “ROOTSYS=<builddir>”, I get: libRInside.so => /usr/lib/R/site-library/RInside/lib/libRInside.so
Manually executing: export LD_LIBRARY_PATH="/usr/lib/R/site-library/RInside/lib:${LD_LIBRARY_PATH}"
fixes the problem and then the R tutorials work also when “ROOTSYS=/tmp/root”.
Thank you for also trying that scenario (installation to a user-defined prefix) on your machine – your findings are again consistent with the additional issue I reported yesterday.
As a follow-up, I will check for broken libraries in my installation and build directories just as you did – good idea that didn’t occur to me yesterday. I even expect that more libraries are broken aside from those relevant for execution of R code as there is the reported dicrepancy between libraries loaded when executing ROOT from the build tree or the installation prefix (at least on my machine and for my installation). I think I will also try if it is possible to manually fix this issue by (re-)setting the broken links in the installation. Might not prove to be the best (and not a systematic) idea, but we’ll see.
I will report on the results of my checking, but I am afraid that I will only be able to do that on Monday as I will be working from at home for the rest of this week.
Checking for broken libraries in my installation and build directories like @Wile_E_Coyote proposed shows the exact same behavior as stated in his report.
The check also shows the issue is not in any way connected to missing/broken (file) links as I naively expected, but rather is due to the libraries themselves being broken.