This is a guide to installation and administration for R.
The current version of this document is 2.8.0 (2008-10-20).
ISBN 3-900051-09-7
Sources, binaries and documentation for R can be obtained via
CRAN, the “Comprehensive R Archive Network” whose current
members are listed at cran.r-project.org/mirrors.html.
The simplest way is to download the most recent R-x.y.z.tar.gz file, and unpack it with
tar xvfz R-x.y.z.tar.gz
on systems that have GNU tar installed. On other systems you need at least to have the gzip program installed. Then you can use
gzip -dc R-x.y.z.tar.gz | tar xvf -
The pathname of the directory into which the sources are unpacked should not contain spaces, as make (specifically GNU make 3.80) does not expect spaces.
If you need to transport the sources on floppy disks, you can download the R-x.y.z.tar.gz-split.* files and paste them together at the destination with (Unix)
cat R-x.y.z-split.* > R-x.y.z.tar.gz
and proceed as above. If you want the build to be usable by a group of
users, set umask before unpacking so that the files will be
readable by the target group (e.g., umask 022 to be usable by all
users). (Keep this setting of umask whilst building and
installing.)
A patched version of the current release, `r-patched' and the current development version, `r-devel', are available as daily tarballs and via access to the R Subversion repository. (For the two weeks prior to the release of a minor (2.x.0) version, `r-patched' will refer to beta/release candidates of the upcoming release, the patched version of the current release being available only via Subversion.)
The tarballs are available from
ftp://ftp.stat.math.ethz.ch/pub/Software/R/. Download
either R-patched.tar.gz or R-devel.tar.gz (or the
.tar.bz2 versions) and unpack as described in the previous
section. They are built in exactly the same way as distributions of R
releases.
Sources are also available via https://svn.R-project.org/R/, the R
Subversion repository. If you have a Subversion client (see
subversion.tigris.org), you
can check out and update the current r-devel from
https://svn.r-project.org/R/trunk/ and the current r-patched from
`https://svn.r-project.org/R/branches/R-x-y-branch/'
(where x and y are the major and minor number of the current
released version of R). E.g., use
svn checkout https://svn.r-project.org/R/trunk/ path
to check out `r-devel' into directory path. The alpha, beta and RC versions of an upcoming x.y.0 release are available from `https://svn.r-project.org/R/branches/R-x-y-branch/' in the four-week period prior to the release.
Note that `https:' is required, and that the SSL certificate for the Subversion server of the R project is
Certificate information:
- Hostname: svn.r-project.org
- Valid: from Jul 16 08:10:01 2004 GMT until Jul 14 08:10:01 2014 GMT
- Issuer: Department of Mathematics, ETH Zurich, Zurich, Switzerland, CH
- Fingerprint: c9:5d:eb:f9:f2:56:d1:04:ba:44:61:f8:64:6b:d9:33:3f:93:6e:ad
(currently, there is no “trusted certificate”). You can accept this certificate permanently and will not be asked about it anymore.
Note that retrieving the sources by e.g. wget -r or svn export from that URL will not work: the Subversion information is needed to build R.
The Subversion repository does not contain the current sources for the
recommended packages, which can be obtained by rsync or
downloaded from CRAN. To use rsync to install the
appropriate sources for the recommended packages, run
./tools/rsync-recommended from the top-level of the R sources.
If downloading manually from CRAN, do ensure that you have the correct versions of the recommended packages: if the number in the file VERSION is `x.y.z' you need to download the contents of `http://CRAN.R-project.org/src/contrib/dir', where dir is `x.y.z/Recommended' for r-devel or x.y-patched/Recommended for r-patched, respectively, to directory src/library/Recommended in the sources you have unpacked. After downloading manually you need to execute tools/link-recommended from the top level of the sources to make the requisite links in src/library/Recommended. A suitable incantation from the top level of the R sources using wget might be
wget -r -l1 --no-parent -A\*.gz -nd -P src/library/Recommended \
http://CRAN.R-project.org/src/contrib/dir
./tools/link-recommended
R will configure and build under a number of common Unix and Unix-alike platforms including `cpu-*-linux-gnu' for the `alpha', `arm', `hppa', `ix86', `ia64', `m68k', `mips', `mipsel', `powerpc', `s390', `sparc', and `x86_64' CPUs, `powerpc-apple-darwin', `i386-apple-darwin' and `sparc-sun-solaris', as well as probably (it is tested less frequently on these platforms) `i386-*-freebsd', `x86_64-*-freebsd', `i386-*-netbsd', `i386-*-openbsd', `i386-sun-solaris', `mips-sgi-irix' and `alpha-dec-osf*'.
In addition, binary distributions are available for some common Linux distributions and for Mac OS X. See the FAQ for current details. These are installed in platform-specific ways, so for the rest of this chapter we consider only building from the sources.
First review the essential and useful tools and libraries in Essential and useful other programs under Unix, and install those you want or need. Ensure that the environment variable TMPDIR is either unset (and /tmp exists and can be written in and executed from) or points to a valid temporary directory.
Choose a place to install the R tree (R is not just a binary, but has additional data sets, help files, font metrics etc). Let us call this place R_HOME. Untar the source code. This should create directories src, doc, and several more. (At this point North American readers should consult Setting paper size.) Issue the following commands:
./configure
make
(See Using make if your make is not called `make'.)
Then check the built system works correctly by
make check
Failures are not necessarily problems as they might be caused by missing
functionality,1 but you
should look carefully at any reported discrepancies. (Some non-fatal
errors are expected in locales that do not support Latin-1, in
particular in true C locales and non-UTF-8 non-European locales.)
A falure in tests/ok-errors.R may indicate inadequate resource
limits (see Running R).
To re-run the tests including those successfully run you would need
make check FORCE=FORCE
More comprehensive testing can be done by
make check-devel
or
make check-all
see tests/README.
If the command configure and make commands execute successfully, the R binary will be copied to R_HOME/bin/exec/R. In addition, a shell-script front-end called R will be created and copied to the same directory. You can copy this script to a place where users can invoke it, for example to /usr/local/bin/R. You could also copy the man page R.1 to a place where your man reader finds it, such as /usr/local/man/man1. If you want to install the complete R tree to, e.g., /usr/local/lib/R, see Installation. Note: you do not need to install R: you can run it from where it was built.
You do not necessarily have to build R in the top-level source directory (say, TOP_SRCDIR). To build in BUILDDIR, run
cd BUILDDIR
TOP_SRCDIR/configure
make
and so on, as described further below. This has the advantage of always keeping your source tree “clean” and is particularly recommended when you work with a version of R from Subversion. (You may need GNU make to allow this, and the pathname of the build directory should not contain spaces.)
Make will also build plain text help pages as well as HTML and
LaTeX versions of the R object documentation (the three kinds can
also be generated separately using make help, make html
and make latex).
For those obtaining R via Subversion, one additional step is necessary:
make vignettes
which makes the grid vignettes (which are contained in the tarballs): it takes several minutes.
Now rehash if necessary, type R, and read the R manuals
and the R FAQ (files FAQ or
doc/manual/R-FAQ.html, or
CRAN.R-project.org/doc/FAQ/R-FAQ.html which always has
the latest version).
There is a set of manuals that can be built from the sources,
To make these, use
make dvi to create DVI versions make pdf to create PDF versions make info to create info files (not `refman').
You will not be able to build any of these unless you have makeinfo version 4.7 or later installed, and for DVI or PDF you must have texi2dvi and texinfo.tex installed (which are part of the GNU texinfo distribution but are, especially texinfo.tex, often made part of the TeX package in re-distributions).
The DVI versions can be previewed and printed using standard programs such as xdvi and dvips. The PDF versions can be viewed using Acrobat Reader or (fairly recent versions of) xpdf and ghostscript: they have hyperlinks that can be followed in the first two. The info files are suitable for reading online with Emacs or the standalone GNU Info. The DVI and PDF versions will be created using the papersize selected at configuration (default ISO a4): this can be overridden by setting R_PAPERSIZE on the make command line, or setting R_PAPERSIZE in the environment and using make -e. (If re-making the manuals for a different papersize, you should first delete the file doc/manual/version.texi.)
There are some issues with making the reference manual, and in particular with the PDF version refman.pdf. The help files contain both ISO Latin1 characters (e.g. in text.Rd) and upright quotes, neither of which are contained in the standard LaTeX Computer Modern fonts. We have provided four alternatives:
timeslmwww.ctan.org/tex-archive/fonts/ps-type1/lm and
mirrors. This uses fonts rather similar to Computer Modern, but is not
so good on-screen as times.
cm-superwww.ctan.org/tex-archive/fonts/ps-type1/cm-super
and its mirrors. These type-1 fonts have poor hinting and so are
nowhere near so readable on-screen as the other three options.
aeThe default can be overridden by setting the environment variables
R_RD4PDF and R_RD4DVI. (On Unix, these will be picked up
at install time.) The default value for R_RD4PDF is
times,hyper: omit hyper if you do not want hyperlinks,
e.g. for printing. The default for R_RD4DVI is ae.
To ensure that the installed tree is usable by the right group of users,
set umask appropriately (perhaps to `022') before unpacking
the sources and throughout the build process.
After
./configure
make
make check
(or, when building outside the source,
TOP_SRCDIR/configure, etc) have been completed
successfully, you can install the complete R tree to your system by
typing
make install
This will install to the following directories:
where prefix is determined during configuration (typically /usr/local) and can be set by running configure with the option --prefix, as in
./configure --prefix=/where/you/want/R/to/go
This causes make install to install the R executable to /where/you/want/R/to/go/bin, and so on. The prefix of the installation directories can be seen in the status message that is displayed at the end of configure. You can install into another directory tree by using
make prefix=/path/to/here install
at least with GNU make (but not e.g. Solaris 8's make).
More precise control is available at configure time via options: see configure --help for details. (However, many of them are currently unused.)
Configure options --bindir and --mandir are supported and govern where a copy of the R script and the man page are installed.
The configure option --libdir controls where the main R files are installed: the default is `eprefix/LIBnn', where eprefix is the prefix used for installing architecture-dependent files, defaults to prefix, and can be set via the configure option --exec-prefix.
Each of bindir, mandir and libdir can also be
specified on the make install command line (at least for GNU
make).
The configure or make variables rdocdir and
rsharedir can be used to install the system-independent
doc and share directories to somewhere other than
libdir. The C header files can be installed to the value of
rincludedir: note that as the headers are not installed into a
subdirectory you probably want something like
rincludedir=/usr/local/include/R-2.8.0.
If you want the R home to be something other than libdir/R, use rhome: for example
make install rhome=/usr/local/lib64/R-2.6.0
will use a version-specific R home on a Linux 64-bit system.
If you have made R as a shared/dynamic library you can install it in your system's library directory by
make prefix=/path/to/here install-libR
where prefix is optional, and libdir will give more
precise control.
make install-strip
will install stripped executables, and on platforms where this is supported, stripped libraries in directories lib and modules and in the standard packages.
To install DVI, info and PDF versions of the manuals, use one or more of
make install-dvi
make install-info
make install-pdf
Once again, it is optional to specify prefix, libdir or
rhome (the DVI and PDF manuals are installed under the R home
directory).
More precise control is possible. For info, the setting used is that of
infodir (default `prefix/info', set by configure
option --infodir). The DVI and PDF files are installed into
the R doc tree, set by the make variable
rdocdir.
A staged installation is possible, that it is installing R into a
temporary directory in order to move the installed tree to its final
destination. In this case prefix (and so on) should reflect
the final destination, and DESTDIR should be used: see
http://www.gnu.org/prep/standards/html_node/DESTDIR.html
Parallel makes are supported for making R only, not for installation nor for checking.
You can uninstall R by
make uninstall
specifying prefix etc in the same way as specified for
installation.
This will also uninstall any installed manuals. There are specific targets to uninstall DVI, info and PDF manuals in doc/manual/Makefile.
Some platforms can support closely related builds of R which can share all but the executables and dynamic objects. Examples include builds under Solaris for different chips (in particular, 32- and 64-bit builds), 64- and 32- bit builds on `x86_64' Linux and different CPUs (`ppc', `ppc64', `i386' and `x86_64') under Mac OS >= 10.4.
R supports the idea of architecture-specific builds, specified by
adding `r_arch=name' to the configure line. Here
name can be anything non-empty, and is used to name subdirectories
of lib, etc, include and libs. Example
names from other systems are the use of sparcv9 on Sparc Solaris
and 32 by gcc on `x86_64' Linux.
If you have two or more such builds you can install them over each other (and for 32/64-bit builds on one architecture, one build can be done without `r_arch'). The space savings can be considerable: on `x86_64' Linux a basic install (without debugging symbols) took 63Mb, and adding a 32-bit build added 6Mb. If you have installed multiple builds you can select which build to run by
R --arch=name
and just running `R' will run the last build that was installed.
R CMD INSTALL will detect if more than one build is installed and
try to install packages with the appropriate library objects for each.
This will not be done if the package has an executable configure
script or a src/Makefile file. In such cases you can install for
extra builds by
R --arch=name CMD INSTALL --libs-only pkg(s)
If you want to mix sub-architectures compiled on different platforms (for example `x86_64' Linux and `i686' Linux), it is wise to use explicit names for each, and you may also need to set libdir to ensure that they install into the same place.
When sub-architectures are used the version of Rscript in e.g. /usr/bin will be the last installed, but architecture-specific versions will be available in e.g. /usr/lib64/R/bin/exec${R_ARCH}. Normally all installed architectures will run on the platform so the architecture of Rscript does not matter.
On Linux, there is an alternative mechanism for mixing 32-bit and 64-bit libraries known as multilib. If a Linux distribution supports multilib, then parallel builds of R may be installed in the sub-directories lib (32-bit) and lib64 (64-bit). The build to be run may then be chosen using the setarch command. For example, a 32-bit build may be chosen by
setarch i686 R
The setarch command is only operational if both 32-bit and 64-bit builds are installed. If there is only one installation of R, then this will always be run regardless of the architecture specified by the setarch command.
There can be problems with installing packages on the non-native
architecture. It is a good idea to run e.g. setarch i686 R for
sessions in which packages are to be installed, even if that is the only
version of R installed (since this tells the package installation
code the architecture needed).
At present there is a protential problem with packages using Java, as the post-install for a `i386' RPM on `x86_64' Linux reconfigures Java and will find the `x86_64' Java. If you know where a 32-bit Java is installed you may be able to run (as root)
export JAVA_HOME=<path to jre directory of 32-bit Java>
setarch i686 R CMD javareconf
to get a suitable setting.
When this mechanism is used, the version of Rscript in e.g. /usr/bin will be the last installed, but an architecture-specific version will be available in e.g. /usr/lib64/R/bin. Normally all installed architectures will run on the platform so the architecture of Rscript does not matter.
The bin/windows directory of a CRAN site contains binaries for a base distribution and a large number of add-on packages from CRAN to run on Windows 2000 or later on ix86 CPUs (including AMD64/EM64T chips and Windows x64).
Your file system must allow long file names (as is likely except perhaps for some network-mounted systems).
Installation is via the installer R-2.8.0-win32.exe. Just double-click on the icon and follow the instructions. You can uninstall R from the Control Panel. (Note that you will probably (depending on the Windows language settings) be asked to choose a language for installation, and that choice applies to both installation and un-installation but not to running R itself.)
See the R Windows FAQ for more details.
If you want to build R from the sources, you will first need to
collect, install and test an extensive set of tools. See The Windows toolset (and perhaps updates in
www.murdoch-sutherland.com/Rtools) for details.
The Rtools.exe executable installer described in The Windows toolset also includes some additions to the R source as
noted below. You should run it first, to obtain a working tar
and other necessities. Choose a “Full installation”, and install
the extra files into your intended R source directory, e.g.
C:/R. The directory name should not contain spaces. We
will call this directory R_HOME below.
To avoid warnings you may want to set the environment variable CYGWIN to `nodosfilewarning'.
You need to collect the following sets of files:
tar zxvf R-2.8.0.tar.gz
to create the source tree in R_HOME. Beware: do use tar to extract the sources rather than tools such as WinZip that do not understand about symbolic links.
It is also possible to obtain the source code using Subversion; see Obtaining R for details.
make
link-recommended. If you have an Internet
connection, you can do this automatically using
make rsync-recommended
math-atlas.sourceforge.net) tuned to your system for fast linear
algebra routines. Pre-built Rblas.dll for various CPUs are
available in the windows/contrib/ATLAS area on CRAN.
If you are building R from source, there are macros USE_ATLAS and
ATLAS_PATH in the file MkRules. Set USE_ATLAS =
YES and ATLAS_PATH to where the ATLAS libraries are located.
You will need to make the libraries yourself2: none of the binaries
we have seen are compiled for the correct compiler. Since R has its
own `xerbla' it is necessary to delete that in ATLAS by
ar d /path/to/libf77blas.a xerbla.o
There used to be support for AMD's AMD Core Math Library (ACML) and Kazushige Goto's BLAS, but neither is currently available for use with the current compilers used.
The following additional items are normally installed by Rtools.exe. If instead you choose to do a completely manual build (or a cross-build), you will also need
libpng and jpeg sources (available, e.g., from
http://www.libpng.org,
ftp://ftp.uu.net/graphics/[png,jpeg],
http://www.libtiff.org. You will need files
libpng-1.2.18.tar.gz, jpegsrc.v6b.tar.gz,
tiff-3.8.0.tar.gz or later.
Working in the directory R_HOME/src/gnuwin32/bitmap,
install the libpng and jpeg sources in sub-directories.
The libpng sub-directory must be named libpng (as required
by the libpng documentation). The jpeg sub-directory for
version 6b is named jpeg-6b; if you use a different version, edit
Makefile and change the definition of JPEGDIR.
Example:
> tar xzvf libpng-1.2.20.tar.gz
> mv libpng-1.2.20 libpng
> tar xzvf jpegsrc.v6b.tar.gz
> tar xzvf tiff-3.8.2.tar.gz
> mv tiff-3.8.2/libtiff .
> rm -rf libtiff-3.8.2
You may need to compile under a case-honouring file system: we found that a samba-mounted file system (which maps all file names to lower case) did not work.
Open a command window at R_HOME/src/gnuwin32. Edit MkRules to set the appropriate paths as needed and to set the type(s) of help that you want built. Beware: MkRules contains tabs and some editors (e.g., WinEdt) silently remove them. Then run
make all recommended
and sit back and wait while the basic compile takes place.
Notes:
malloc in the file
R_HOME/src/gnuwin32/malloc.c is used for R's internal memory
allocations. You can opt out of this by commenting the line
LEA_MALLOC=YES in MkRules, in which case the
malloc in msvcrt.dll is used. This does work but
imposes a considerable performance penalty.
make -j2 all
make recommended
but this is only likely to be worthwhile on a dual-processor/dual-core machine with ample (at least 384Mb) of memory. (On a dual AthlonMP it reduced the build time by about 30%.) Note that this may sometimes stop and have to be restarted.
The file R_HOME/bin/Rbitmap.dll is not built automatically.
Running make in R_HOME/src/gnuwin32/bitmap
or make bitmapdll in R_HOME/src/gnuwin32
should build Rbitmap.dll and install it in R_HOME/bin.
You can test a build by running make check. You may need to set
TMPDIR to the absolute path to a suitable temporary directory: the
default is `c:/TEMP'. (Use forward slashes and do not use a path
including spaces. It will be ignored if not set to a directory.)
The recommended packages can be checked by
make check-recommended
Other levels of checking are
make check-devel
for a more thorough check of the R functionality, and
make check-all
for check-devel and check-recommended.
The PDF manuals can be made by
make manuals
If you want to make the info versions (not the Reference Manual), use
cd ../../doc/manual
make -f Makefile.win info
To make DVI versions of the manuals use
cd ../../doc/manual
make -f Makefile.win dvi
(all assuming you have tex and latex installed and in your path).
See the Making the manuals section in the Unix section for setting options such as the paper size.
You need to have the files for a complete R build, including bitmap and Tcl/Tk support and the manuals, as well as the recommended packages and Inno Setup (see The Inno Setup installer).
Once everything is set up
make distribution
make check-all
will make all the pieces and the installers and put them in the gnuwin32/cran subdirectory, then check the build. This works by building all the parts in the sequence:
Rpwd.exe (a utility needed in the build) rbuild (the executables, the FAQ docs etc.) rpackage (the base packages) htmldocs (the HTML documentation) bitmapdll (the bitmap support files) recommended (the recommended packages) vignettes (the vignettes in package grid: only needed if building from svn checkout) manuals (the PDF manuals) rinstaller (the install program) crandir (the CRAN distribution directory)
The parts can be made individually if a full build is not needed, but earlier parts must be built before later ones. (The Makefile doesn't enforce this dependency—some build targets force a lot of computation even if all files are up to date.) The first four targets are the default build if just `make' is run.
If you want to customize the installation by adding extra packages,
replace make rinstaller by something like
make rinstaller EXTRA_PKGS='pkg1 pkg2 pkg3'
An alternative way to customize the installer starting with a binary distribution is to first make a full installation of R from the standard installer (that is, select `Full Installation' from the `Select Components' screen), then add packages and make other customizations to that installation. Then in src/gnuwin32/installer run
make myR IMAGEDIR=rootdir
where rootdir is the path to the root of the customized installation (forward slashes and no spaces, please). This creates an executable with the standard name, R-2.8.0-win32.exe, so please rename it to indicate that it is customized.
The defaults for the startup parameters may also be customized. For example
make myR IMAGEDIR=rootdir MDISDI=1
will create an installer that defaults to installing R to run in SDI mode. See src/gnuwin32/installer/Makefile for the names and values that can be set.
It is also possible to build an installer for use with Microsoft Installer. This is intended for use by sysadmins doing automated installs, and is not recommended for casual use.
It makes use of the Windows Installer XML (WiX) toolkit (wersion 2.0) available from http://wix.sourceforge.net/. (This needs the .NET 1.1 framework installed: it ran on a vanilla Windows XP SP2 machine. Unfortunately the file format has been changed within the same version: currently our code works with releases 2.0.4221.0 and 2.0.5805.0 – the latter is now said to be `production/stable' so hopefully there will be no more format changes.) Once WiX is installed, set the path to its home directory in MkRules.
You need to have the files for a complete R build, including bitmap and Tcl/Tk support and the manuals, as well as the recommended packages. Then
cd installer
make msi
which will results in a file of about 40Mb with a name like R-2.6.0-win32.msi. This can be double-clicked to be installed, but those who need it will know what to do with it.
Thanks to David del Campo (Dept of Statistics, University of Oxford) for suggesting WiX and building a prototype installer.
It is possible to cross-build R or packages on (at least) `ix86' and `x86_64' Linux, and the `ix86' cross-compilers have also been used successfully on `x86_64' Linux.
The preferred build environment is to use gcc 4.2.1: this can easily be built from the sources as a cross-compiler, but the MinGW-specific patches are not yet stable (and not needed to build R).
You will need suitable cross-compilers installed and in your path. We do not at present distribute suitable cross-compilers.
For Fedora 8 and 9 users, RPMs are available at http://sourceforge.net/projects/mingw-cross/ for both `ix86' and `x86_64'. (Currently there are Fedora 8 RPMs for 4.3.0 and Fedora 9 RPMs for both 4.3.0 and 4.3.1. The Fedora 8 `x86_64' RPMs have been tested.) Recent Debian and Ubuntu versions have C/C++ (but it seems not Fortran) cross-compilers based on gcc 4.2.1.
You will need Perl, zip and unzip installed and (to
make the manuals) makeinfo version 4.7 or later (part of GNU
texinfo) as well as texinfo.tex.
You also need the R source (R-2.8.0.tar.gz), the Tcl/Tk support files and iconv.dll (see above).
Then: untar R-2.8.0.tar.gz somewhere, unpack R_Tcl.zip at the top level and put iconv.dll in src/gnuwin32/unicode, then
cd /somewhere/R-2.8.0/src/gnuwin32
Edit MkRules to set BUILD=CROSS and the appropriate paths
(including HEADER if needed).
Edit MkRules to set the type(s) of help that you want built. (You
will not be able to cross-build .chm files, so WINHELP is
automatically set to NO.)
You also need a working copy of this version of R on Linux:
uncomment and set R_EXE in MkRules to point to it.
Then run make (and parallel make works reliably, unlike on Windows).
Packages can be made in the same way as natively: see Customizing package compilation under Windows, via the Makefiles but not via `R CMD INSTALL'. So care is needed where packages have dependencies: Linux versions of the dependencies must be installed in a library in the search path. So for example to cross-build the MCMCpack package we used
# MCMCpack depends on coda, so point to the library containing it
export R_LIBS=/R/library
make PKGDIR=/mysources pkg-MCMCpack
make PKGDIR=/mysources lazyload-MCMCpack
cd ../../library
zip -r9X /dest/MCMCpack_0.7-4.zip MCMCpack
Even so, packages which depend on others that need to run compiled code to load may not work (methods is a special exception).
To distribute a cross-build (or just to transfer it to a Windows machine for testing) use
make all recommended manuals
cd installer
make imagedir
zip -r9X R-2.8.0.zip R-2.8.0 # or something similar
Note that .chm help files (the default for a vanilla binary installation) will not be made when cross-building.
Also based on this facility is Makefile-rcb by J. Yan and A. J. Rossini. For details, see the Makefile-rcb file itself, or http://cran.r-project.org/doc/contrib/cross-build.pdf.
The bin/macosx directory of a CRAN site contains binaries for Mac OS X for a base distribution and a large number of add-on packages from CRAN to run on Mac OS X version 10.4.4 or higher.
The simplest way is to use R-2.8.0.dmg. Just double-click on the icon and the disk image file will be mounted. Read the ReadMe.txt inside the disk image and follow the instructions.
See the R for Mac OS X FAQ for more details.
If you want to build this port from the sources, you can read the above mentioned R for Mac OS X FAQ for full details. You will need to collect and install some tools as explained in the document. Then you have to expand the R sources and configure R appropriately, for example
tar zxvf R-2.8.0.tar.gz
cd R-2.8.0
./configure --with-blas='-framework vecLib' --with-lapack \
--with-aqua --enable-R-framework
make
and then sit back and wait. The first two options are the default (and
strongly recommended), and with some toolsets have been essential. The
second line of options is also default on Mac OS X, but needed only if
you want to build R for use with R.app Console, and imply
--enable-R-shlib to build R as a shared/dynamic library.
These options configure R to be built and installed as a framework called R.framework. The default path for R.framework is /Library/Frameworks but this can be changed at configure time specifying the flag --enable-R-framework[=DIR] or at install time as
make prefix=/where/you/want/R.framework/to/go install
the R.framework has not to be specified in the path.
Note that building the R.app GUI console is a separate project: see the FAQ for details.
How to start R and what command-line options are available is discussed in Invoking R.
You should ensure that the shell has set adequate resource limits: R expects a stack size of at least 8MB and to be able to open at least 256 file descriptors. (Any modern OS will have default limits at least as large as these, but apparently NetBSD does not.)
R makes use of a number of environment variables, the default values of many of which are set in file R_HOME/etc/Renviron (there are none set by default on Windows and hence no such file). These are set at configure time, and you would not normally want to change them – a possible exception is R_PAPERSIZE (see Setting paper size). As from R 2.4.0 the paper size will be deduced from the `LC_PAPER' locale category if it exists and R_PAPERSIZE is unset, and this will normally produce the right choice from `a4' and `letter' on modern Unix-alikes (but can always be overridden by setting R_PAPERSIZE).
Various environment variables can be set to determine where R creates its per-session temporary directory. The environment variables TMPDIR, TMP and TEMP are searched in turn and the first one which is set and points to a writable area is used. If none do, the final default is /tmp on Unix-alikes and the value of R_USER on Windows.
Some Unix-alike systems are set up to remove files and directories periodically from /tmp, for example by a cron job running tmpwatch. Set TMPDIR to another directory before running long-running jobs on such a system.
Note that TMPDIR will be used to execute configure
scripts when installing packages, so if /tmp has been mounted as
`noexec', TMPDIR needs to be set to a directory from which
execution is allowed.
It is helpful to use the correct terminology. A package is
loaded from a library by the function library(). Thus a
library is a directory containing installed packages; the main library
is R_HOME/library, but others can be used, for example by
setting the environment variable R_LIBS or using the R function
.libPaths().
The set of packages loaded on startup is by default
> getOption("defaultPackages")
[1] "datasets" "utils" "grDevices" "graphics" "stats" "methods"
(plus, of course, base) and this can be changed by setting the option in startup code (e.g. in ~/.Rprofile). It is initially set to the value of the environment variable R_DEFAULT_PACKAGES if set (as a comma-separated list). Setting R_DEFAULT_PACKAGES=NULL ensures that only package base is loaded.
Changing the set of default packages is normally used to reduce the set for speed when scripting: in particular not using methods will reduce the start-up time by a factor of three or more. But it can also be used to customize R, e.g. for class use.
R packages are installed into libraries, which are directories in the file system containing a subdirectory for each package installed there.
R comes with a single library, R_HOME/library which is the value of the R object `.Library' containing the standard and recommended3 packages. Both sites and users can create others and make use of them (or not) in an R session. At the lowest level `.libPaths()' can be used to add paths to the collection of libraries or to report the current collection.
As from R 2.5.0 R will automatically make use of a site-specific library R_HOME/site-library if this exists (it does not in a vanilla R installation). This location can be overridden by setting4 `.Library.site' in R_HOME/etc/Rprofile.site, or (not recommended) by setting the environment variable R_LIBS_SITE. Like `.Library', the site libraries are always included by `.libPaths()'.
As from R 2.5.0 users can have one or more libraries, normally specified by the environment variable R_LIBS_USER. This has a default value (use `Sys.getenv("R_LIBS_USER")' within an R session to see what it is), but only is used if the corresponding directory actually exists (which by default it will not).
Both R_LIBS_USER and R_LIBS_SITE can specify multiple library paths, separated by colons (semicolons on Windows).
Packages may be distributed in source form or compiled binary form. Installing source packages requires that compilers and tools (including Perl 5.8.0 or later) be installed. Binary packages are platform-specific and generally need no special tools to install, but see the documentation for your platform for details.
Note that you need to specify implicitly or explicitly the library to which the package is to be installed. This is only an issue if you have more than one library, of course.
For most users it suffices to call `install.packages(pkgname)' or its GUI equivalent if the intention is to install a CRAN package and internet access is available.5 On most systems `install.packages()' will allow packages to be selected from a list box.
To install packages from source in Unix use
R CMD INSTALL -l /path/to/library pkg1 pkg2 ...
The part `-l /path/to/library' can be omitted, in which case the first library in R_LIBS is used if set, otherwise the main library R_HOME/library is used. (R_LIBS is looked for in the environment: note that .Renviron is not read by R CMD.) Ensure that the environment variable TMPDIR is either unset (and /tmp exists and can be written in and executed from) or points to a valid temporary directory.
There are a number of options available: use R CMD INSTALL --help
to see the current list.
Alternatively, packages can be downloaded and installed from within
R. First set the option CRAN to your nearest CRAN
mirror using chooseCRANmirror(). Then download
and install packages pkg1 and pkg2 by
> install.packages(c("pkg1", "pkg2"))
The essential dependencies of the specified packages will also be fetched.
Unless the library is specified (argument lib) the first library
in the library search path is used: if this is not writable, R will
ask the user (in an interactive session) if the default user library
should be created, and if allowed to will install the packages there.
If you want to fetch a package and all those it depends on that are not already installed, use e.g.
> install.packages("Rcmdr", dependencies = TRUE)
install.packages can install a source package from a local
.tar.gz file by setting argument repos to NULL.
install.packages can look in several repositories, specified as a
character vector by the argument repos: these can include a
CRAN mirror, Bioconductor, Omegahat, local archives, local
files, ...).
What install.packages does by default is different on Unix and
Windows. On Unix-alikes it consults the list of available source
packages on CRAN (or other repository/ies), downloads the
latest version of the package sources, and installs them (via R
CMD INSTALL). On Windows it looks (by default) at the list of
binary versions of packages available for your version of R
and downloads the latest versions (if any), although optionally it will
also download and install a source package by setting the type
argument.
On Windows install.packages can also install a binary package
from a local zip file by setting argument repos to
NULL. Rgui.exe has a menu Packages with a GUI
interface to install.packages, update.packages and
library.
R CMD INSTALL works in Windows to install source packages if
you have the source-code package files (option “Source Package
Installation Files” in the installer) and toolset (see The Windows toolset) installed. Installation of binary packages must be done by
install.packages. R CMD INSTALL --help will tell you
the current options under Windows (which differ from those on a
Unix-alike): in particular there is a choice of the types of
documentation to be installed.
If you have only a source package that is known to work with current R and just want a binary Windows build of it, you could make use of the building service offered at win-builder.r-project.org.
On Mac OS X install.packages works as it does on other Unix-like
systems, but there is an additional type mac.binary that can be
passed to install.packages in order to download and install
binary packages from a suitable repository, and is the default for
CRAN builds of R. These Macintosh binary package files have the
extension `tgz'. The R GUI provides for installation of
either binary or source packages, from CRAN or local files.
The R system and package-specific compilation flags can be overridden or
added to by setting the appropriate Make variables in the personal file
$HOME/.R/Makevars-$R_PLATFORM, or if that does not exist,
$HOME/.R/Makevars, where `R_PLATFORM' is the platform for
which R was built, as available in the platform component of the
R variable R.version.
Package developers are encouraged to use this mechanism to enable a reasonable amount of diagnostic messaging (“warnings”) when compiling, such as e.g. -Wall -pedantic for tools from GCC, the Gnu Compiler Collection.
This section describes ways to customize package compilation using the standard C, C++ and FORTRAN compilers and tools. For instructions on using non-standard tools, see the README.packages file.
The Makefiles can be customized: in particular the name of the DLL can
be set (for example we once needed integrate-DLLNM=adapt), the
compile flags can be set (see the examples in MakeDll) and the
types of help (if any) to be generated can be chosen (variables
HELP, HELPTYPES and WINHELP). The simplest way to
customize the compilation steps is to set variables in a file
src/Makevars.win, which will automatically be included by
MakeDLL. For example, for RODBC src/Makevars.win could
include the line
DLLLIBS+=-lodbc32
or, equivalently,
RODBC-DLLLIBS=-lodbc32
but in fact contains the single line
PKG_LIBS=-lodbc32
If you have a file src/Makefile.win, that will be used as the makefile for source compilation in place of our makefile and MakeDll and src/Makevars.win will be ignored.
Package-specific compilation flags can be overridden or added to using
the personal file $HOME/.R/Makevars.win, or if that does not
exist, $HOME/.R/Makevars. (See the rw-FAQ for the meaning
of $HOME.) For the record, the order of precedence is (last wins)
Beware: references to variables in R.dll are converted to the right form by using the header files. You must include them.
For additional control, R_HOME/src/gnuwin32/Makefile
contains additional make targets corresponding to various options to
R CMD INSTALL. These assume that package foo's source
code has been installed in directory
R_HOME/src/library/foo. Then make pkg-foo is similar
to R CMD INSTALL foo (but the latter would require
R_HOME/src/library to be the current directory). Other
targets are
ziponly-foo, to use zip to compress the help files after building
the package.
ziphelp-foo to both compress the help files and to keep the
originals.
zipdata-foo to compress the data files. This is recommended if
you have either many small data files (as in package Devore5) or a
few large data files.
pkgcheck-foo to check the package (like R CMD check foo).
Using this approach allows variables to be set during the build, e.g.
make PKGDIR=/mysources RLIB=/R/library pkg-foo
Some variables that may be used include:
DEBUG=T to compile with debugging information for gdb.
PKG_CFLAGS= to specify options to the C compiler.
PKG_CPPFLAGS= to specify options to the preprocessor.
PKG_CXXFLAGS= to specify options to the C++ compiler.
PKG_FFLAGS= to specify options to the FORTRAN 77 compiler.
PKG_FCFLAGS= to specify options to the Fortran 95 compiler (if
specified).
PKG_LIBS= to specify options to the linking step making the DLL.
PKGDIR=/path/to/source to specify the path to the package source files.
RLIB=/path/to/library to specify the path to the library
where the package should be installed.
PKG_* flags are those
typically included in Makevars files.
The command update.packages() is the simplest way to ensure that
all the packages on your system are up to date. Set the repos
argument as in the previous section. The update.packages()
downloads the list of available packages and their current versions,
compares it with those installed and offers to fetch and install any
that have later versions on the repositories.
An alternative interface to keeping packages up-to-date is provided by
the command packageStatus(), which returns an object with
information on all installed packages and packages available at multiple
repositories. The print and summary methods give an
overview of installed and available packages, the upgrade method
offers to fetch and install the latest versions of outdated packages.
Packages can be removed in a number of ways. From a command prompt they can be removed by
R CMD REMOVE -l /path/to/library pkg1 pkg2 ...
From a running R process they can be removed by
> remove.packages(c("pkg1", "pkg2"),
lib = file.path("path", "to", "library"))
Finally, in most installations one can just remove the package directory from the library.
Note: only remove.packages can remove package
bundles.
Utilities such as install.packages can be pointed at any
CRAN-style repository, and R users may want to set up their own. The
`base' of a repository is a URL such as
http://www.omegahat.org/R: this must be an URL scheme that
download.packages supports (which also includes `ftp://' and
`file://'). Under that base URL there should be directory trees
for one or more of the following types of package distributions:
"source": located at src/contrib and containing
.tar.gz files.
"win.binary": located at bin/windows/contrib/x.y for
R versions x.y.z and containing .zip files.
"mac.binary": located at
bin/macosx/universal/contrib/x.y for R versions x.y.z
and containing .tgz files. If the repository contains only
packages for a specific architecture, the package distribution type
can be set to "mac.binary.xxx" where xxx specifies the
architecture, replacing universal by xxx in the path
above.
Each terminal directory must also contain a PACKAGES file. This
can be a concatenation of the DESCRIPTION files of the packages
separated by blank lines (provided there are no bundles), but only a few
of the fields are needed. The simplest way to set up such a file is to
use function write_PACKAGES in the tools package, and its
help explains which fields are needed. Optionally there can also be
a PACKAGES.gz file, a gzip-compressed version of
PACKAGES—as this will be downloaded in preference to
PACKAGES it should be included for large repositories.
To add your repository to the list offered by setRepositories(),
see the help file for that function.
As from R 2.7.0 a repository can contain subdirectories, when the descriptions in the PACKAGES file of packages in subdirectories must include a line of the form
Path: path/to/subdirectory
The write_PACKAGES utility in package tools can help
prepare the PACKAGES and PACKAGES.gz files.
Internationalization refers to the process of enabling support for non-English languages, and localization to adapting to a specific country and language.
R long worked in the ISO Latin-1 8-bit character set and so covered English and most Western European languages (if not necessarily their currency symbols). Since R 2.1.0 it has supported (where possible) multi-byte character sets such as UTF-8 and others used in Chinese, Japanese and Korean.
Full internationalization of the character sets is enabled unless R is built under Unix-alikes using configure option --disable-mbcs provided the OS can support it: see Configuration on Unix. Under Windows, support for Windows' own MBCS is always included.
All builds of R support all single-byte character sets that the
underlying OS can handle. These are interpreted according to the
current locale, a sufficiently complicated topic to merit a
separate section. Fully internationalized builds can also handle most
multi-byte locales, in which a single character is represented by one,
two or more consecutive bytes: examples of such locales are those using
UTF-8 (becoming standard under Linux but non-existent under Windows) and
those for Chinese, Japanese and Korean.
The other aspect of the internationalization is support of the translation of messages. This is enabled in almost all builds of R.
A locale is a description of the local environment of the user,
including the preferred language, the encoding of characters, the
currency used and its conventions, and so on. Aspects of the locale are
accessed by the R functions Sys.getlocale and
Sys.localeconv.
The system of naming locales is OS-specific. There is quite wide agreement on schemes, but not on the details of their implementation. A locale needs to specify
R is principally concerned with the first (for translations) and third. Note that the charset may be deducible from the language, as some OSes offer only one charset per language, and most OSes have only one charset each for many languages. Note too the remark above about Chinese.
Modern Linux uses the XPG locale specifications which have the form `en_GB', `en_GB.utf8', `aa_ER.utf8@saaho', `de_AT.iso885915@euro', the components being in the order listed above. (See man locale and locale -a for more details.) Similar schemes (but often in different cases) are used by most Unix-alikes.
Windows also uses locales, but specified in a rather less concise way.
Most users will encounter locales only via drop-down menus, but more
information and lists can be found at
msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt_language_and_country_strings.asp.
Mac OS X supports locales in its own particular way, but the R GUI tries
to make this easier for users. See
developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/
for how users can set their locales. As with Windows, end users will generally only see lists of languages/territories. Users of R in a terminal may need to set the locale to something like `en_GB.UTF-8' if it defaults to `C'.
Internally Mac OS X uses a form similar to Linux but without
specifying the encoding (which is UTF-8). It is based on ICU
locales (http://icu.sourceforge.net/userguide/locale.html) and
not POSIX ones.
The preferred language for messages is by default taken from the locale. This can be overridden first by the setting of the environment variable LANGUAGE and then by the environment variables LC_ALL, LC_MESSAGES and LANG. (The last three are normally used to set the locale and so should not be needed, but the first is only used to select the language for messages.) The code tries hard to map locales to languages, but on some systems (notably Windows) the locale names needed for the environment variable LC_ALL do not all correspond to XPG language names and so LANGUAGE may need to be set. (One example is `LC_ALL=es' on Windows which sets the locale to Estonian and the language to Spanish.)
It is usually possible to change the language once R is running
via (not Windows) Sys.setlocale("LC_MESSAGES",
"new_locale"), or by setting an environment variable such as
LANGUAGE, provided6 the language you are changing to can be output in the current
character set.
Messages are divided into domains, and translations may be available for some or all messages in a domain. R makes use of the following domains.
R for basic C-level error messages.
R-pkg for the R stop, warning and
message messages in each package, including R-base for the
base package.
RGui for the menus etc of the R for Windows GUI front-end.
Dividing up the messages in this way allows R to be extensible: as packages are loaded, their message translation catalogues can be loaded too.
Translations are looked for by domain according to the currently specified language, as specifically as possible, so for example an Austrian (`de_AT') translation catalogue will be used in preference to a generic German one (`de') for an Austrian user. However, if a specific translation catalogue exists but does not contain a translation, the less specific catalogues are consulted. For example, R has catalogues for `en_GB' that translate the Americanisms (e.g., `gray') in the standard messages into English. Two other examples: there are catalogues for `es', which is Spanish as written in Spain and these will by default also be used in Spanish-speaking Latin American countries, and also for `pt_BR', which are used for Brazilian locales but not for locales specifying Portugal.
Translations in the right language but the wrong charset be made use of by on-the-fly re-encoding (on almost all systems). The LANGUAGE variable (only) can be a colon-separated list, for example `se:de', giving a set of languages in decreasing order of preference. One special value is `en@quot', which can be used in a UTF-8 locale to have English/American error messages with pairs of quotes translated to Unicode directional quotes.
If no suitable translation catalogue is found or a particular message is not translated in any suitable catalogue, English is used.
See developer.r-project.org/Translations.html for how to prepare
and install translation catalogues.
Many current CPUs have both 32- and 64-bit sets of instructions: this has long been true for UltraSparc and more recently for MIPS, PPC and `x86_64' (AMD Opteron and Athlon64, Intel Xeon and Pentium/'Core' supporting EM64T). Many OSes running on such CPUs offer the choice of building a 32-bit or a 64-bit version of R (and details are given below under specific OSes). For most a 32-bit version is the default, but for some (e.g., `x86_64' Linux) 64-bit is.
All current versions of R use 32-bit integers and IEC 605597 double-precision reals, and so compute to the same precision8 and with the same limits on the sizes of numerical quantities. The principal difference is in the size of the pointers.
64-bit builds have both advantages and disadvantages:
R allocates memory for large objects as needed, and removes any unused ones at garbage collection. When the sizes of objects become an appreciable fraction of the address limit, fragmentation of the address space becomes an issue and there may be no hole available that is the size requested. This can cause more frequent garbage collection or the inability to allocate large objects. As a guide, this will become an issue with objects more than 10% of the size of the address space (around 300Mb) or when the total size of objects in use is around one third (around 1Gb).
So, for speed you may want to use a 32-bit build, but to handle large datasets (and perhaps large files) a 64-bit build. You can build both and install them in the same place: See Sub-architectures.
Even on 64-bit builds of R there are limits on the size of R
objects (see help("Memory-limits"), some of which stem from the
use of 32-bit integers (especially in FORTRAN code). On all versions of
R, the maximum length (number of elements) of a vector is
2^31-1, about 2 billion, and on 64-bit systems the size of a
block of memory allocated is limited to 2^34-1 bytes (8GB). It
is anticipated these will be raised eventually but routine use of 8GB
objects is (in 2005) several years off.
Currently the Windows build of R is a 32-bit executable. This runs happily on Windows 64 on AMD64 and EM64T, but is limited to (we are told) a 2GB address space. It will not be possible to provide a native version for Windows 64 until suitable compilers are available, and currently (mid-2007) that is not imminent.10
The routines supporting the distribution and special11 functions in R and a few others are declared in C header file Rmath.h. These can be compiled into a standalone library for linking to other applications. (Note that they are not a separate library when R is built, and the standalone version differs in several ways.)
The makefiles and other sources needed are in directory src/nmath/standalone, so the following instructions assume that is the current working directory (in the build directory tree on Unix if that is separate from the sources).
Rmath.h contains `R_VERSION_STRING', which is a character
string containing the current R version, for example "2.6.0".
There is full access to R's handling of NaNs, Inf and
-Inf via special versions of the macros and functions
ISNAN, R_FINITE, R_log, R_pow and R_pow_di
and (extern) constants R_PosInf, R_NegInf and NA_REAL.
There is no support for R's notion of missing values, in particular
not for NA_INTEGER nor the distinction between NA and
NaN for doubles.
A little care is needed to use the random-number routines. You will need to supply the uniform random number generator
double unif_rand(void)
or use the one supplied (and with a shared library or DLL you will have to use the one supplied, which is the Marsaglia-multicarry with an entry point
set_seed(unsigned int, unsigned int)
to set its seeds).
The facilties to change the normal random number generator are available through the constant N01_kind. This takes values from the enumeration type
typedef enum {
BUGGY_KINDERMAN_RAMAGE,
AHRENS_DIETER,
BOX_MULLER,
USER_NORM,
INVERSION,
KINDERMAN_RAMAGE
} N01type;
(and `USER_NORM' is not available).
If R has not already be made in the directory tree, configure must tbe run as described in the main build instructions.
Then
make
will make standalone libraries libRmath.a and libRmath.so.
`make static' and make shared will create just one of them.
NB: certain compilers are unable to do compile-time IEEE-754
arithmetic and so cannot compile mlutils.c and several other
files. The known example is earlier versions of Sun's cc
(e.g. Forte 6 and 7): the Sun Studio 11 suite does work.
To use the routines in your own C or C++ programs, include
#define MATHLIB_STANDALONE
#include <Rmath.h>
and link against -lRmath (and -lm if needed on your OS).
The example file test.c does nothing useful, but is provided to
test the process (via make test. Note that you will probably
not be able to run it unless you add the directory containing
libRmath.so to the LD_LIBRARY_PATH environment variable.
The targets
make install
make uninstall
will (un)install the header Rmath.h and shared and static
libraries (if built). Both prefix= and DESTDIR are
supported, together with more precise control as described for the main
build.
`make install' installs a file for pkg-config to use by e.g.
$(CC) pkg-config --cflags libRmath` -c test.c
$(CC) `pkg-config --libs libRmath` test.o -o test
On some systems `make install-strip' will install a stripped shared library.
You need to set up almost all the tools to make R and then run (in a Unix-like shell)
(cd ../../include; make -f Makefile.win config.h Rconfig.h Rmath.h)
make -f Makefile.win
For cmd.exe use
cd ../../include
make -f Makefile.win config.h Rconfig.h Rmath.h
cd ../nmath/standalone
make -f Makefile.win
This creates a static library libRmath.a and a DLL Rmath.dll. If you want an import library libRmath.dll.a (you don't need one), use
make -f Makefile.win shared implib
To use the routines in your own C or C++ programs using MinGW, include
#define MATHLIB_STANDALONE
#include <Rmath.h>
and link against -lRmath. This will use the first found of
libRmath.dll.a, libRmath.a and Rmath.dll in that
order, so the result depends on which files are present. You should be
able to force static or dynamic linking via
-Wl,-Bstatic -lRmath -Wl,dynamic
-Wl,-Bdynamic -lRmath
or by linking to explicit files (as in the `test' target in
Makefile.win: this makes two executables, test.exe which
is dynamically linked, and test-static, which is statically
linked).
It is possible to link to Rmath.dll using other compilers, either directly or via an import library: if you make a MinGW import library as above, you will create a file Rmath.def which can be used (possibly after editing) to creat an import library for other systems such as Visual C++.
If you make use of dynamic linking you should use
#define MATHLIB_STANDALONE
#define RMATH_DLL
#include <Rmath.h>
to ensure that the constants like NA_REAL are linked correctly.
(Auto-import will probably work with MinGW, but it is better to be
sure. This is likely to also work with VC++, Borland and similar
compilers.)
This appendix gives details of programs you will need to build R on Unix-like platforms, or which will be used by R if found by configure.
Remember that some package management systems (such as RPM and deb) make a distinction between the user version of a package and the development version. The latter usually has the same name but with the extension `-devel' or `-dev': you need both versions installed.
You need a means of compiling C and FORTRAN 77 (see Using FORTRAN). Some add-on packages also need a C++ compiler. Your C
compiler should be IEC 6005912, POSIX 1003.1 and C99-compliant if at all
possible. R tries to choose suitable flags for the C compilers it
knows about, but you may have to set CC or CFLAGS
suitably. For recent versions of gcc with glibc this
means including -std=gnu9913. If the compiler is
detected as gcc, -std=gnu99 will be appended to
CC unless it conflicts with a setting of CFLAGS.
Unless you do not want to view graphs on-screen you need `X11' installed, including its headers and client libraries. (On Fedora Core 3 and SuSE 9.x Linux this meant the `xorg-x11-devel' and `xorg-x11-libs' RPMs. For recent Fedora distributions it means (at least) `libX11', `libX11-devel', `libXt' and `libXt-devel'. On Debian we recommend the meta-package `xorg-dev'.) If you really do not want these you will need to explicitly configure R without X11, using --with-x=no.
The command-line editing depends on the readline library
available from any GNU mirror: version 4.2 or later is
needed for all the features to be enabled. Otherwise you will need to
configure with --with-readline=no (or equivalent).
The use of multi-byte characters, conversion between encodings
(including for translated messages) and the R iconv function
depend on having the system iconv function: this is part of
recent versions of glibc and many Unixes. You can also install
GNU libiconv (which is not the same as that in
glibc), possibly as a plug-in replacement: see
www.gnu.org/software/libiconv. Note that the R usage
requires iconv to be able to translate between "latin1"
and "UTF-8", to recognize "" as the current encoding and
to translate to and from the Unicode wide-character formats
"UCS-[24][BL]E" – this is not true of most commercial Unixes.
This is regarded as essential from R 2.5.0: if you do not have it
will need to configure with --without-iconv (or equivalent),
and make check (and other checks) are likely to fail.
Perl version 5.8.0 or later, available via
www.perl.com/CPAN is
essential.
You will not be able to build most of the manuals unless you have makeinfo version 4.7 or later installed, and if not some of the HTML manuals will be linked to CRAN. (Version 4.6 is known to create incorrect HTML files.) To make DVI or PDF versions of the manuals you will also need texinfo.tex installed (which is part of the GNU `texinfo' distribution but is often made part of the TeX package in re-distributions) as well as texi2dvi (part of the GNU texinfo distribution).
The DVI and PDF documentation and building vignettes needs tex and latex, or pdftex and pdflatex.
If you want to build from the R Subversion repository you need both makeinfo and pdflatex.
The ability to use translated messages makes use of gettext and
most likely needs GNU gettext: you do need this to work
with new translations, but otherwise the version contained in the R
sources will be used if no suitable external gettext is found.
The `modern' version of X11, jpeg(), png() and
tiff() uses the cairo and (optionally) Pango
libraries. Cairo version 1.0 or later is required14, and some features reguire 1.2
or later (and may not work before 1.4). Pango needs to be at least
version 1.10, and 1.12 is the earliest version we have tested. (For
Fedora users we believe the pango-devel RPM and its dependencies
suffice.) R checks for pkg-config, and uses that to check
first that the `pangocairo' package is installed (and if not,
`cairo') and if additional flags are needed for the
`cairo-xlib' package, then if suitable code can be compiled. These
tests will fail if pkg-config is not installed, and are likely
to fail if cairo was built statically (unusual). Most systems
with Gtk+ 2.8 or later installed will have suitable libraries,
but some (e.g. Solaris 10) may need cairo added separately.
Mac OS X comes with none of these libraries, but cairo support
has been added to the binary distribution.
For the best font experience with these devices you need suitable fonts
installed: Linux users will want the urw-fonts package. Another
useful set of fonts is the `liberation' truetype fonts available at
https://www.redhat.com/promo/fonts/, which cover the Latin, Greek
and Cyrillic alphabets plus a fair range of signs. These share metrics
with Arial, Times New Roman and Courier New, and contain fonts rather
similar to the first two
(http://en.wikipedia.org/wiki/Liberation_fonts).
The bitmapped graphics devices jpeg(), png() and
tiff() need the appropriate headers and libraries installed:
jpeg (version 6b or later) or libpng (version 1.2.3 or
later) and zlib (version 1.1.3 or later) or libtiff (any
recent version – 3.8.2 was tested) respectively.
The bitmap and dev2bitmap devices and also
embedFonts() use ghostscript (www.cs.wisc.edu/~ghost).
If you have them installed (including the appropriate headers and of
recent enough versions), zlib, libbz2 and PCRE will be
used if specified by --with-system-zlib,
--with-system-bzlib or --with-system-pcre: otherwise
versions in the R sources will be compiled in. As the latter suffice
and are tested with R you should not need to change this. In
particular, the version of zlib 1.2.3 in the R sources has
enhancements to work with large file systems on 32-bit platforms.
Use of the X11 clipboard selection requires the Xmu headers and
libraries. These are normally part of an X11 installation (e.g. the
Debian meta-package `xorg-dev'), but some distributions have split
this into smaller parts, so for example recent versions of Fedora
require the `libXmu' and `libXmu-devel' RPMs.
Some systems (notably Mac OS X and at least some FreeBSD systems) have
inadequate support for collation in multibyte locales. It is possible
to replace the OS's collation support by that from ICU (International
Components for Unicode, http://www.icu-project.org), and this
provides much more precise control over collation on all systems. ICU
is available as sources and as binary distributions for (at least) most
Linux distributions, Solaris 9/10, AIX and Windows, usually as libicu or
icu4c.
The tcltk package needs Tcl/Tk >= 8.3 installed: the sources are
available at www.tcl.tk. To specify
the locations of the Tcl/Tk files you may need the configuration options
or use the configure variables TCLTK_LIBS and
TCLTK_CPPFLAGS to specify the flags needed for linking against
the Tcl and Tk libraries and for finding the tcl.h and
tk.h headers, respectively. If you have both 32- and 64-bit
versions of Tcl/Tk installed, setting the paths to the correct config
files may be necessary to avoid confusion between them.
Versions of Tcl/Tk from 8.3 to 8.5.0 have been used successfully.
configure looks for Java support on the host system, and if it finds it sets some settings which are useful for Java-using packages. JAVA_HOME can be set during the configure run to point to a specific JRE/JDK.
Principal amongst these are some library paths to the Java libraries and JVM, which are stored in environment variable R_JAVA_LD_LIBRARY_PATH in file R_HOME/etc/ldpaths (or a sub-architecture-specific version). A typical setting for Sun Java is
/usr/java/jdk1.5.0_06/jre/lib/amd64/server:/usr/java/jdk1.5.0_06/jre/lib/amd64
Note that this unfortunately depends on the exact version of the JRE/JDK
installed, and so will need updating if the Java installation is
updated. This can be done by running R CMD javareconf. The
script re-runs Java detection in a manner similar to that of the
configure script and updates settings in both Makeconf and
R_HOME/etc/ldpaths. See R CMD javareconf --help for
details.
Another alternative of overriding those setting is to set R_JAVA_LD_LIBRARY_PATH (e.g. in ~/.Renviron), or use /etc/ld.so.conf to specify the Java runtime library paths to the system. Other settings are recorded in etc/Makeconf (or a sub-architecture-specific version), e.g.
JAVA = /usr/bin/java
JAVAC = /usr/bin/javac
JAVA_HOME = /usr/java/jdk1.5.0_06/jre
JAVA_LD_LIBRARY_PATH = $(JAVA_HOME)/lib/amd64/server:$(JAVA_HOME)/lib/amd64:\
$(JAVA_HOME)/../lib/amd64:/usr/local/lib64
JAVA_LIBS = -L$(JAVA_HOME)/lib/amd64/server -L$(JAVA_HOME)/lib/amd64
-L$(JAVA_HOME)/../lib/amd64 -L/usr/local/lib64 -ljvm
where `JAVA_LIBS' contains flags necessary to link JNI programs.
Some of the above variables can be queried using R CMD config.
The linear algebra routines in R can make use of enhanced BLAS (Basic
Linear Algebra Subprograms, www.netlib.org/blas/faq.html) routines. However, as from R
2.4.015 these have to be explicitly
requested at configure time: R provides an internal BLAS which is
well-tested and will be adequate for most uses of R.
You can specify a particular BLAS library via a value for the
configuration option --with-blas and not to use an external
BLAS library by --without-blas (the default). If
--with-blas is given with no, its value is taken from the
environment variable BLAS_LIBS, set for example in
config.site. If neither the option nor the environment variable
supply a value, a search is made for a suitable BLAS. If the value is
not obviously a linker command (starting with a dash or giving the path
to a library), it is prefixed by -l, so
--with-blas="foo"
is an instruction to link against -lfoo to find an external BLAS
(which needs to be found both at link time and run time).
The configure code checks that the external BLAS is complete (it must
include all double precision and double complex routines16, as well as
LSAME), and appears to be usable. However, an external BLAS has
to be usable from a shared object (so must contain position-independent
code), and that is not checked.
Some enhanced BLASes are compiler-system-specific (libsunperf on
Sun Sparc17, libessl on IBM, vecLib on Mac OS X). The
correct incantation for these is usually found via
--with-blas with no value on the appropriate platforms.
Some of the external BLASes are multi-threaded. One issue is that R
profiling (which uses the SIGPROF signal) may cause problems, and
you may want to disable profiling if you use a multi-threaded BLAS.
Note that using a multi-threaded BLAS can result in taking more CPU time
and even more elapsed time (occ