I'm unable to install Boom 0.9 on Ubuntu 18.04, Boom 0.8 installs without issue. However, we need 0.9 as a pre-req for CausalImpact.
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
/usr/lib/R/etc/Makeconf:176: recipe for target 'Models/Glm/PosteriorSamplers/fill_poisson_mixture_approximation_table_2.o' failed
make[1]: *** [Models/Glm/PosteriorSamplers/fill_poisson_mixture_approximation_table_2.o] Error 4
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/tmp/RtmpKl6J7B/R.INSTALL90e7ca998b2/Boom/src'
ERROR: compilation failed for package 'Boom'
* removing '/usr/local/lib/R/site-library/Boom'
The downloaded source packages are in
'/tmp/RtmpIk7UFT/downloaded_packages'
Warning message:
In install.packages("Boom") : installation of one or more packages failed,
probably 'Boom'
I've ensured that build-essential is up to date with the most current version available (and tried g++-8 as well).
I think someone else in your org may have already contacted me about this. We are mid-flight debugging.
Boom is a large package and can time out when building. The first thing to check is that you are able to build with multiple cores (i.e. you can pass the -j x flag to make).
As a diagnostic you can try building the package without involving R. Clone https://github.com/steve-the-bayesian/BOOM and build with either bazel (up to date) or make (not too far out of date). If this build succeeds then compare flags passed to the R build vs the native build.
To better understand where R is failing, download the Boom package from CRAN https://cran.r-project.org/src/contrib/Boom_0.9.1.tar.gz and try the following from the command line
R CMD CHECK Boom_0.9.1.tar.gz
This will probably fail, but it will generate a directory called Boom.Rcheck, which contains a file 00install.out containing all the compiler output.
It is suspicious that the build above fails on the poisson_mixture_approximation_table, which is a large file that might be overflowing your stack. Or that might be a coincidence.
Take a look at: https://cran.r-project.org/web/checks/check_results_Boom.html
The check page says 'GNU make' is a undeclared SystemRequirement.
Version: 0.9.1
Check: for GNU extensions in Makefiles
Result: NOTE
GNU make is a SystemRequirements.
Since your installation process also seems to fail at make[1] it might make sense to check if GNU make is installed.
The installation of the Boom package from source (also during the Docker build) can fail for several reasons:
low memory pro core
low stack size
timeout of the build process (possible)
We are currently using the following setup for Docker:
core: 4
memory: 8GB
We can use the following command to set the stack size to 16MB before starting the installation:
Docker:
RUN ulimit -s 16384 \
&& R -e 'install.packages("Boom");'
Linux:
ulimit -s 16384 \
&& R -e 'install.packages("Boom");'
Note: The stack size is an operating system-related configuration and can vary depending on the host operating system used.
Note: The command to install the boom package may be different for your application. We use for example packrat.
Similar issue: link
Related
I am deploying multiple R versions on multiple virtual desktops. I've built 3.6.3 and 4.1.2 R from source on Ubuntu 18.04.3 LTS. None of them finds the system-wide Rprofile.site file in /etc/R or the system certificates in /usr/share/ca-certificates. However R (3.4.4) installed with APT has no such problems. I used Ansible, but for the sake of this question I reproduced the deployment for one host with a shell script.
#!/bin/bash
set -euo pipefail
# install build dependecies
(command -v apt && apt-get build-dep r-base) || (command -v dnf && dnf builddep R)
version='4.1.2'
major_version=$(echo "$version" | cut -c 1)
wget "https://cran.rstudio.com/src/base/R-$major_version/R-$version.tar.gz"
tar -xzf R-$version.tar.gz
cd R-$version
./configure \
--prefix=/opt/R/$version \
--sysconfdir=/etc/R \
--enable-R-shlib \
--with-pcre1 \
--with-blas \
--with-lapack
make -j 8
make install
Note: It should run on most Linux distros with APT or RPM package managers. Increase the -j argument of make, if you have the enough cores, but no time.
So I defined the installation prefix as /opt/R/$version , but I want it read config files from /etc/R (defined --sysconfdir=/etc/R). However when I open the R interactive shell (/opt/R/4.1.2/bin/R) to try install a package:
install.packages("remotes")
then I will be prompted to choose a R package mirror, but one already defined in /etc/R/Rprofile.site:
local({
r <- getOption("repos")
r["CRAN"] <- "https://cloud.r-project.org"
options(repos = r)
})
I can force the R shell to find the Rprofile.site file by defining it with the R_PROFILE environment variable.
export R_PROFILE=/etc/R/Rprofile.site
/opt/R/4.1.2/bin/R
then call install.packages("remotes") again in the R shell. Now no mirror selection prompt will be shown, but the following error:
Warning: unable to access index for repository https://cloud.r-project.org/src/contrib:
cannot open URL 'https://cloud.r-project.org/src/contrib/PACKAGES'
Warning message:
package ‘remotes’ is not available for this version of R
A version of this package for your version of R might be available elsewhere,
see the ideas at
https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages
So it cannot access the repository index (real problem), then concludes that the package ‘remotes’ package is not available for my R version. Which is BS, since it was not able to read the index at the first place. So I tried a simple HTTP call in the same R shell.
curlGetHeaders("https://example.com")
and got this error:
Error in curlGetHeaders("https://example.com") : libcurl error code 77:
unable to access SSL/TLS CA certificates
So it cannot find the CA certificates in /usr/share/ca-certificates.
Since the R installed by APT has none of these problems. The compiled R does not search the right places. Even if I omit the --sysconfdir=/etc/R build option and copy or symlink the /etc/R directory under the prefix, so it will be at /opt/R/4.1.2/etc. It will still not find its config files.
The greater problem that I do not even no know how to specify the /usr/share so it may find the certificates. The rsharedir build options (the -- also missing in the makefile) will not do, because it should point to /usr/share/R/ not /usr/share, which would be a bad practice anyway.
I also tried all of this it with the 3.6.3 R version and got the same results.
Questions: How can I make the compiled R installations to find the system-wide or any config files and the certificates.
Update 1
I ran the build script on a Ubuntu server which I do not manage with the same Ansible code. On both of them R successfully finds the certificates. So the problem is not with the build script but the system state.
Update 2
I created a simple R script (install-r-package.R) which install a package:
install.packages("renv", repos="https://cran.wu.ac.at/")
then I executed it with Rscript and traced which file do they open on both the correct and erroneous hosts:
strace -o strace.log -e trace=open,openat,close,read,write,connect,accept ./Rscript install-r-package.R
It turned out that on the problematic system R does not even try to open the certificate files.
The relevant trace snippet on the correct system:
connect(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("137.208.57.37")}, 16) = -1 EINPROGRESS (Operation now in progress)
openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 6
read(6, "-----BEGIN CERTIFICATE-----\nMIIH"..., 200704) = 200704
read(6, "--\n", 4096) = 3
read(6, "", 4096) = 0
close(6) = 0
on the problematic system:
connect(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("137.208.57.37")}, 16) = -1 EINPROGRESS (Operation now in progress)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so", O_RDONLY|O_CLOEXEC) = 6
read(6, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220A\0\0\0\0\0\0"..., 832) = 832
close(6) = 0
In both cases R connects to the mirror (137.208.57.37) after that on the correct system it reads the ca-certificates.crt certificate file and many other .crt files after that. However the erroneous system jump this step altogether.
Finally I found the solution:
Since both system has the arch and OS. I cross copied the R compiled installations between them. The R which was compiled on the problematic system, but was run on the correct one gave the warnings below after the calling of the install.packages("renv", repos="https://cran.wu.ac.at/")
Warning: unable to access index for repository https://cran.wu.ac.at/src/contrib:
internet routines cannot be loaded
Warning messages:
1: In download.file(url, destfile = f, quiet = TRUE) :
unable to load shared object '/opt/R/4.1.2/lib/R/modules//internet.so':
libcurl-nss.so.4: cannot open shared object file: No such file or directory
2: package ‘remotes’ is not available for this version of R
A version of this package for your version of R might be available elsewhere,
see the ideas at
https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Installing-packages
If I do the reverse then the installation works.
The libcurl-nss.so.4: cannot open shared object file: No such file or directory line gave me the clue that different libcurl4 flavors was used as build dependecies. I checked which dev dependecies were installed on the systems and libcurl4-nss-dev 7.58.0-2ubuntu3 were installed on the problematic system and libcurl4-gnutls-dev 7.58.0-2ubuntu3.16 on the correct system.
So I purged libcurl4-gnutls-dev from the problematic system:
apt purge libcurl4-nss-dev -y
and installed libcurl4-gnutls-dev:
aptitude install libcurl4-gnutls-dev
I used aptitude, because I had to downgrade libcurl3-gnutls 7.58.0-2ubuntu3.16 (now) -> 7.58.0-2ubuntu3 (bionic) which is a dependency of libcurl4-gnutls-dev, then I run a make clean in the R-4.1.2 source directory. Finally I re-run the build script from the question, and got a well working R, which can read the certificates, hence can reach the HTTPS using package mirrors.
Periodically – I think whenever I update R – I have problems installing packages from source on my 64-bit Windows machine.
Today I'm trying to install a package using devtools::install_github(). The installation proceeded fine on my laptop, but my not on my desktop, which can install the package under *** arch - i386, but under *** arch - x64, which reports the error message
C:/PROGRA~1/R/R-34~1.4/bin/x64/R.dll: file not recognized: File format not recognized
The command that caused the error is
C:/Rtools/mingw_32/bin/g++ -shared -s -static-libgcc -o PACKAGENAME.dll [...]
I believe that the error is arising because R is using mingw_32 to attempt to compile a 64-bit package. The question is, where can I tell R to use mingw_64? I've already checked all the places that I can recall:
R-3.4.4/etc/x64/Makeconf states
BINPREF ?= c:/Rtools/mingw_64/bin/
My system PATH (verified from within R using Sys.getenv('PATH')) includes mingw_64 ahead of mingw_32.
R must be looking somewhere else to decide which compiler to use... but where?
Via R CMD check not looking for gcc in Rtools directory:
R was looking in C:/Users/MYUSERNAME/Documents/.R/Makevars for the value of BINPREF. Deleting the contents of this file removed the incorrect location.
$RPATH/etc/i386/Makeconf is re-created with each new installation of R, and contains the line
BINPREF ?= c:/Rtools/mingw_32/bin/.
The ?= operator will set the value of BINPREF if it is not already set, as it was in the Makevars file mentioned above. So replacing ?= with = will work until a new version of R is installed and the Makeconf file is overwritten – updating, or uninstalling, R will not modify the Makevars file in the User directory.
If you start digging from devtools::install_github, it will lead you through the following functions:
devtools::install_github
devtools:::install_remotes
devtools:::try_install_remote
devtools:::install_remote
devtools:::install
devtools:::check_build_tools
devtools:::setup_rtools
devtools:::scan_path_for_rtools
And when you run the following code:
devtools:::scan_path_for_rtools(TRUE)
devtools:::setup_rtools(debug=TRUE)
Most likely, it is saying that Rtools is not currently installed. (Yes, a bit counterintuitive given that you already have it installed in C:/Rtools but maybe not registered in registry)
To fix it, you will need to run (which is in essence the solution in Rtools is not being detected from RStudio)
Sys.setenv(PATH=paste0("C:\\Rtools\\bin;", Sys.getenv("PATH")))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_64/bin", version=3.4), class="rtools"))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_32/bin", version=3.4), class="rtools"))
Please let me know if this works.
BINPREF ?= c:/Rtools/mingw_64/bin/
remove ? before =
I have a general question about how to effectively load any kind of external package into R. I have found that many sources detailing this information are simply insufficient, but I will leave out mentioning those respective URLs. I have successfully loaded external packages into R before, but I am having difficulties loading the fgui package.
In my specific case, I cannot load the library fgui into R Studio. First I download directly from CRAN with the command:
install.packages("fgui", lib="~/Documents/R_dir")
This works fine for me. My working directory is set to ~/Documents/R_dir
The next command I use is:
library("fgui", lib.loc="~/Documents/R_dir")
The error I get is:
Error : .onLoad failed in loadNamespace() for 'tcltk', details:
call: dyn.load(file, DLLpath = DLLpath, ...)
error: unable to load shared object '/Library/Frameworks/R.framework/Versions/3.1/Resources/library/tcltk/libs/tcltk.so':
dlopen(/Library/Frameworks/R.framework/Versions/3.1/Resources/library/tcltk/libs/tcltk.so, 10): Library not loaded: /opt/X11/lib/libX11.6.dylib
Referenced from: /Library/Frameworks/R.framework/Versions/3.1/Resources/library/tcltk/libs/tcltk.so
Reason: image not found
Error: package or namespace load failed for ‘fgui’
I have examined the thread "Error when trying to load library(ggplot2) in R" but it did not answer my question.
Please help me with any suggestions to get the package fgui to work properly in R Studio and feel free to address the more general issue of effectively loading external packages into R.
tcltk is not a typical package. It's probably already installed on your system and it cannot be installed using the usual install.packages procedure because it is not on CRAN (just like the base packages that come with R, like stats, etc.). Also, tcltk2 is not the same as tcltk; that is a package that expands upon (and depends on) the functionality of tcltk.
So, start with this:
> capabilities("tcltk")
tcltk
TRUE
If that comes back FALSE it means that your R was not built with tcltk support. You don't say what OS you're using, so it's a little bit difficult to help you.
That said, if you're on Linux, you need to rebuild R with tcltk support. This should be relatively straightforward. Basically, make sure Tcl and tk are available on your system in a standard location (something like sudo apt-get install tcl8.5-dev tk8.5-dev) and then rebuild R per usual procedures.
If you're on Mac OS, you're encountering the same error that John Fox describes here in relation to Rcmdr. In short, it's probably one of two things:
A file permission issue related to the directory where you have Tcl installed. To quote Fox: "You can verify the source of this problem by issuing the following command at the R command prompt:
system("ls -ld /usr/local /usr/local/lib /usr/local/lib/libtcl*")
# ls: /usr/local/lib: Permission denied
# ls: /usr/local/lib/libtcl*: Permission denied
# drwx------ 8 root wheel 272 Sep 24 10:21 /usr/local
If the output of the system command looks like the above, you should go to Terminal and do the following: sudo chmod -R a+rX /usr/local and enter your password to change directory permissions.
You have an out-dated version of X-Windows. Try running Mac OS Software Update.
It may also be solvable by creating a symbolic link as described in this answer.
This should never come up on Windows, unless you built R from source without tcl/tk support.
On Arch Linux, tk is a separate package from tcl and both need to be installed:
sudo pacman -S tcl tk
This is given that the output from capabilities("tcltk") with R is TRUE (which means your R is compiled with tcltk support as noted previously in the answers here, this should be the case if you installed it from the arch repos).
The official installation instructions for R say:
Note: the use of X11 (including tcltk) requires XQuartz to be
installed since it is no longer part of OS X. Always re-install
XQuartz when upgrading your OS X to a new major version.
So: Simply (re)install XQuartz if you want to use the tcltk package in R.
delete the X11 file on location : /opt
delete the X11 on application unitiltiy
reinstall X11 again
Problem solved...
For Mac-OS users:
I struggled with this problem recently and found that R-3.1.2 has a bug, which assumes that otool is installed when it is not.
R-3.0.0 (and later) ships with Tck/Tk 8.6.0, so you shouldn't need to install that.
Simply upgrading to a more recent version of R (3.4.2) fixed the problem for me.
I had the same issue and went down a rabbit hole before discovering a simple fix. If you install R from bianry it will include tcltk by default. Just run the installer with the default installation. You can get the .dmg here: https://cran.r-project.org/bin/macosx/
Easiest answer for Mac users:
1- Install tcl-tk using brew:
brew install tcl-tk
2- Run the following code:
ln -s /usr/local/Cellar/tcl-tk/$version/lib/libtcl8.6.dylib /usr/local/lib/libtcl8.6.dylib
ln -s /usr/local/Cellar/tcl-tk/$version/lib/libtk8.6.dylib /usr/local/lib/libtk8.6.dylib
Problem solved!
I am having a tough time installing R-packages that are not available in the Anaconda repositories. My attempts so far can be found here How to install R-packages not in the conda repositories?.
Currently, I am trying to build the R-package rafalib for conda by following the instructions from this article under the heading Building a conda R package.
The first part works fine.
conda skeleton cran rafalib
Out:
Tip: install CacheControl to cache the CRAN metadata
Fetching metadata from http://cran.r-project.org/
Writing recipe for rafalib
Done
The build command runs into errors
conda build r-rafalib
Out:
Removing old build environment
Removing old work directory
BUILD START: r-rafalib-1.0.0-r3.2.2_0
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ......
Solving package specifications: .
Error: Packages missing in current linux-64 channels:
- r 3.2.2*
- r-rcolorbrewer
I have r 3.2.2-64bit installed via conda and it runs without problems. I also already have r-colorbrewer installed via conda and I can use that package without issues in R. Why am I getting these errors when trying to build a conda package?
I am on Linux (Antergos, an Arch derivative) with kernel 4.4.5-1-ARCH.
UPDATE 2015/04/19
Thanks to this answer, I found out that I could include the dependencies by building them separately in the same directory as the package I want to install. That didn't work for me, but I also read that I can include a channel in the build command with -c, just as when installing. So now I do:
conda build -c r r-rafalib
This gets passed all the dependency problems, but after fetching, extracting and linking packages, it fails. Here is the end of the error message.
Removing old work directory
Source cache directory is: /home/joel/anaconda2/conda-bld/src_cache
Downloading source to cache: rafalib_1.0.0.tar.gz
Downloading http://cran.r-project.org/src/contrib/rafalib_1.0.0.tar.gz
rafalib_1.0.0. 100% |#######################| Time: 0:00:00 4.87 MB/s
Success
Extracting download
Package: r-rafalib-1.0.0-r3.2.2_0
source tree in: /home/joel/anaconda2/conda-bld/work/rafalib
+ mv DESCRIPTION DESCRIPTION.old
+ grep -v '^Priority: ' DESCRIPTION.old
+ /home/joel/anaconda2/envs/_build/bin/R CMD INSTALL --build .
sh: symbol lookup error: sh: undefined symbol: rl_signal_event_hook
Command failed: /bin/bash -x -e /home/joel/drafts/r-rafalib/build.sh
The error sh: symbol lookup error: sh: undefined symbol: rl_signal_event_hook is the same as I encounter when using install.packages() as reported here.
There is some related discussion in this thread. I have tried to get around this error by installing different versions of ncurses, including this patched version, and I have tried to link the readline libraries, as suggested here, but I keep running into the same error. I'm quite lost at this point and any help to solve this would be greatly appreciated.
Although I started out with a different problem, the final solution turned out to be the same as I posted elsewhere How to install R-packages not in the conda repositories?. I am adding it here for completeness.
In the end, I got around the rl_event_hookproblems by following the approach recommended here and symlinking anaconda's libreadline to the system one:
mv ~/anaconda3/lib/libreadline.s.6.2 ~/anaconda3/lib/libreadline.s.6.2.bak
ln -s /usr/lib/libreadline.so.6.3 ~/anaconda3/lib/libreadline.s.6.2
I am still having troubles installing some dependency heavy R-packages due to failure to load shared objects when using install.packages() from withing R. However, simpler packages work fine and I can get most of the dependency heavy packages from anacondas R-repositories.
Does anyone have a link to clear instructions on how to install and configure the necessary latex packages to build R packages on a mac?
I have some scripts for building and checking R packages on a mac server. They seemed to work fine, but after upgrading to R 3.1.3, many of the packages started failing with
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'networkVignette.tex' failed.
Messages:
sh: /usr/local/bin/texi2dvi: No such file or directory
Calls: <Anonymous> -> texi2pdf -> texi2dvi
Execution halted
I found a thread which seemed to suggest I need a more recent version texinfo (5.2) than what is installed by default. And apparently I've I've got the wrong version installed in the wrong location?
which texi2pdf
/sw/bin/texi2pdf
texi2pdf --version
texi2pdf (GNU Texinfo 5.1) 5234
(same version is reported when running system('texi2pdf --version') in R )
This thread gives a link to a texinfo 5.2 source collection:
http://r.789695.n4.nabble.com/R-CMD-build-looking-for-texi2dvi-in-the-wrong-place-R-devel-td4701706.html
But I'm not familiar with installing executable from a tar.gz file on a mac. The R mac help pages I found suggest installing MacTex, which I tried but that didn't seem to help.
** Update: ** additional discussion of related problems on R-SIG-mac mailing list:
https://groups.google.com/forum/#!topic/r-sig-mac/xjyuFdl5Ezk
Update:
Here is where I'm currently at:
I removed my /sw directory to uninstall fink and all of its packages (couldn't figure out how to upgrade it)
installed homebrew
brew install texinfo installs version 5.2 the package,
but generates the message This formula is keg-only, which means it was not symlinked into /usr/local and actually installs in in /usr/local/Cellar/texinfo/5.2/bin which means it is not on the path and R won't find it.
manually symlink each of the texi2pdf, texi2dvi , etc as vincent suggests (this is because R has the /usr/local/bin location as default in the tools::texi2dvi function?
edited the /etc/paths file on the system to add /usr/local/bin so that finds the brew installed 5.2 version before it finds it before the osx system supplied version 4.6 version. This may not be necessary because R has it hardcoded?
All of this gets rid of the "can't find texi* errors", and gives me a bunch of latex errors (which I don't see on unix and windows builds) so I'm still kind of stuck.
This seems very hackish, so there must be a cleaner way? But it sounds like stuff with tex and mac is very sketchy at the moment? https://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
This worked for me on Mavericks and on Yosemite:
ln -s /usr/bin/texi2dvi /usr/local/bin/texi2dvi
ln -s /usr/bin/texi2pdf /usr/local/bin/texi2pdf
On my Lion system both the command which texi2pdf at a Terminal/bash prompt and from a R.app GUI prompt tell me that I have that program in:
system("which texi2pdf")
#/opt/local/bin/texi2pdf
That is a location typical for MacPorts installation. I think the /usr/local/bin/ is what the binary R version "expects". I'm not really that UNIX savvy, but I think the you can modify the PATH environment variable so that R will be able to find your installation. (Whether it will be compatible I cannot say since so much detail is missing from your question.) My Tex installation is MacTex, which I got from https://www.tug.org/mactex/. I admit to having a cobbled-together system:
system("echo $PATH")
# /opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin
That gets set at the beginning of an R session because this is the first line in my .Rprofile-(invisible)file:
Sys.setenv(PATH="/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin")
I think /sw/bin/ installations signify a fink install, which I have had very little success with. Simon Urbanek suggests not using any package installers, but then leaves the rest of us UNIX weenies very little in the way of worked examples of how to install that various external packages that underpin the many interesting and oh-so-useful R packages. So I feel your pain, but I'm not running for President.
So I suppose you could try this at your R console before again attempting one of the earlier unsuccessful installs:
Sys.setenv(PATH=paste( Sys.getenv()$PATH, # should be the character string of the $PATH
"/sw/bin/", sep=":")
)
Wish I could offer guarantees, but if it breaks the only guarantee is that you get to keep all the pieces.
I ran into a similar error message using Mavericks 10.9.5 (factory configured) and R 3.1.
It turns out that I didn't have pdfLaTex. I went to this page: http://tug.org/mactex/ and downloaded the MacTex installation package. It's big (>2GB) but after I installed it, my R package build problems went away.
Hope this might be helpful to anyone else who runs into this error message.