R packages on CRAN needs to pass a series of technical checks. These checks can also be invoked by any user when running R CMD check
on the package tar.gz
(to emulate CRAN as much as possible one should also set the --as-cran
option when doing so). These checks need to be passed before a package is accepted on CRAN. In addition, these checks are regularly run for each package on CRAN to ensure that new R features or updates of upstream packages do not break the package. Furthermore, CRAN checks regularly become stricter. Thus, keeping a package on CRAN may require regular effort from the package maintainer. Whereas this sometimes can be rather frustrating for the maintainer, partly because of CRAN’s rather short two week limit in case of newly appearing issues, this is one the features that ensures the high technical quality of packages on CRAN.
As an example for the increasingly stricter checks, CRAN now also performs a set of additional checks in addition to the CRAN checks on all R platforms that are shown on a packages check page (e.g., for the MPTmultiverse). These additional checks include tests for memory access errors (e.g., using valgrind
), R compiled using alternative compilers, different numerical algebra libraries, but also tests for an R version without support for long doubles (i.e., noLD
). It now has happened for the second time that one of my packages showed a problem on the R version without long double support
In my case, the problem on the R version without long double support appeared in the package examples or in the unit tests of the package. Therefore, I did not only want to fix the check issue, I also wanted to understand what was happening. Thus, I needed a working version of R
without support for long doubles. Unfortunately, the description of this setup is rather sparse. The only information on CRAN is rather sparse:
tests on x86_64 Linux with R-devel configured using
--disable-long-double
Other details as https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-devel-linux-x86_64-fedora-gcc
Similarly sparse information is given in Writing R Extensions:
If you must try to establish a tolerance empirically, configure and build R with –disable-long-double and use appropriate compiler flags (such as -ffloat-store and -fexcess-precision=standard for
gcc
, depending on the CPU type86) to mitigate the effects of extended-precision calculations.
Unfortunately, my first approach in which I simply tried to add the --disable-long-double
option to the R-devel install script failed. After quite a bit of searching I found the solution on the RStudio community forum thanks to David F. Severski. In addition to --disable-long-double
one also needs to add --enable-long-double=no to configure
. At least on Ubuntu, this successfully compiles an R
version without long double support. This can be confirmed with a call to capabilities()
in R
.
The rest of this post gives a list of all the packages I needed to install on a fresh Ubuntu version to successfully compile R in this way (e.g., from here). This set of packages should of course also hold for compiling normal R versions. I hope I did not forget too many packages, but this hopefully covers most. Feel free to post a comment if something is missing and I will try to update the list.
sudo apt-get update sudo apt-get install build-essential sudo apt-get install gfortran sudo apt-get install gcc-multilib sudo apt-get install gobjc++ sudo apt-get install libpcre2-dev sudo apt-get install xorg-dev sudo apt-get install libcurl4-openssl-dev sudo apt-get install libbz2-dev sudo apt-get install liblzma-dev sudo apt-get install libblas-dev sudo apt-get install texlive-fonts-extra sudo apt-get install default-jdk sudo apt-get install aptitude sudo aptitude install libreadline-dev sudo apt-get install curl
In addition to the necessary packages, the following packages probably lead to a better R user experience (after installing these a restart may help):
sudo apt-get install xfonts-100dpi sudo apt-get install xfonts-75dpi sudo apt-get install qpdf sudo apt-get install pandoc sudo apt-get install libssl-dev sudo apt-get install libxml2-dev sudo apt-get install git sudo apt-get install gdebai-core sudo apt-get install libcairo2-dev sudo apt-get install libtiff-dev
The last two packages should allow you to add --with-cairo=yes
to the configure script below. The package above might be needed for installing RStudio.
After this, we should be able to build R. For this, I followed the `RStudio` instructions for installing multiple R versions in parallel. We begin by setting an environment variable and downloading R.
export R_VERSION=4.0.1 curl -O https://cran.rstudio.com/src/base/R-4/R-${R_VERSION}.tar.gz tar -xzvf R-${R_VERSION}.tar.gz cd R-${R_VERSION}
We can then install R
(here I set the options for disabling long doubles):
./configure \ --prefix=/opt/R/${R_VERSION} \ --enable-R-shlib \ --with-blas \ --with-lapack \ --disable-long-double \ --enable-long-double=no make sudo make install
To test the installation we can use:
/opt/R/${R_VERSION}/bin/R --version
Finally, we need to create a symbolic link:
sudo ln -s /opt/R/${R_VERSION}/bin/R /usr/local/bin/R sudo ln -s /opt/R/${R_VERSION}/bin/Rscript /usr/local/bin/Rscript
We can then run R
and check the capabilities of the installation:
> capabilities() jpeg png tiff tcltk X11 FALSE TRUE FALSE FALSE TRUE aqua http/ftp sockets libxml fifo FALSE TRUE TRUE TRUE TRUE cledit iconv NLS profmem cairo TRUE TRUE TRUE FALSE FALSE ICU long.double libcurl TRUE FALSE TRUE
Or shorter:
> capabilities()[["long.double"]] [1] FALSE
Hi Henrik,
Thank you for sharing the details. I have a question and would like to ask for your help. I was recently notified that I need to correct the ‘noLD’ issue of my package to retain the package on CRAN. However, I searched online and found sparse information on how to reproduce the ‘noLD’ error.
Just would like to confirm with you that by installing a R version without long double support and running “R CMD check mypackage.tar.gz”, I should be able to reproduce the ‘noLD’ error? Thank you very much.
Best wishes,
Cong
Yes. And it also worked like that in my case. With the version described here, I could reproduce the issue on a test system and then fix it.