This is a guide to installation and administration for R.
The current version of this document is 1.9.1 (2004-06-21). ISBN 3-900051-02-X
Sources, binaries and documentation for R can be obtained via
CRAN, the "Comprehensive R Archive Network". See the file
RESOURCES in the R distribution for information on
CRAN.
The simplest way is to download the most recent
R-x.y.z.tgz file, and unpack it with
tar xvfz R-x.y.z.tgz
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.tgz | tar xvf -
If you need to transport the sources on floppy disks, you can download
the R-x.y.z.tgz-split.* files and paste them
together at the destination with (Unix)
cat R-x.y.z-split.* > R-x.y.z.tgz
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).
A patched version of the current release, r-patched and the
current development version, r-devel, are available as daily
tarballs and via rsync. The development version is also available by
anonymous CVS from http://anoncvs.r-project.org/.
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.
These versions do not contain the current sources for the recommended
packages, which can be obtained by rsync (see the next section) or 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/x.y.z/Recommended
to directory src/library/Recommended in the sources you have
unpacked. Normally R-patched.tar.gz will have the number of the
last released version, and R-devel.tar.gz that of the next minor
(x.y.0) release. 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.
One way to download the package sources is to use wget. A
suitable incantation from the top level of the R sources might be
wget -r -l1 --no-parent -A\*.gz -nd -P src/library/Recommended \
http://cran.r-project.org/src/contrib/x.y.z/Recommended
tools/link-recommended
Sources are also available via anonymous rsync. Use
rsync -rC --delete rsync.r-project.org::module R
to create a copy of the source tree specified by module in the
subdirectory R of the current directory, where module can
be one of r-release (current released version), r-patched
(patched released version), and r-devel (development version).
The rsync trees are created directly from the master CVS archive and are
updated hourly. The -C option in the rsync command
is to cause it to skip the CVS directories. Further information on
rsync is available at http://rsync.samba.org/rsync/.
Note that the sources available via rsync do not include the recommended
packages, whereas these are included in the tarballs of released
versions. To install the appropriate sources for the recommended
packages, run ./tools/rsync-recommended from the top-level of
the R sources.
R will configure and build under a number of common Unix platforms including i386-freebsd, cpu-linux-gnu for the i386, alpha, amd64, arm, hppa, ia64, m68k, powerpc, and sparc CPUs (see e.g. http://buildd.debian.org/build.php?&pkg=r-base) and sparc-sun-solaris, as well as probably (it is tested less frequently on these) i386-netbsd, i386-openbsd, i386-sun-solaris, powerpc-apple-darwin, mips-sgi-irix, alpha-dec-osf4, rs6000-ibm-aix and hppa-hp-hpux.
In addition, binary distributions are available for most common Linux distributions, and for Mac OS X (Darwin) with and without X11. 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, and install those you want or
need. Ensure that the environment variable TMPDIR is either
unset 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. 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, but you should look carefully at any reported discrepancies. To re-run the tests 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 these commands execute successfully, the R binary will be copied
to the R_HOME/bin directory. 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". (You may need GNU make to
allow this.)
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). Note that you need Perl version 5: if this is
not available on your system, you can obtain PDF versions of the
documentation files via CRAN.
Now rehash if necessary, type R, and read the R manuals
and the R FAQ (files FAQ or
doc/html/faq.html, or
http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html which always has
the latest version).
There is a set of manuals that can be built from the sources,
refman
R-FAQ
R-intro
R-data
R-admin
R-exts
R-lang
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 the info files unless you have
makeinfo version 4 or later installed.
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) ghostscript:
they have hyperlinks that can be followed in Acrobat Reader. The info
files are suitable for reading online with Emacs or the standalone GNU
Info.
After
./configure
make
make check
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:
/bin
/man/man1
/lib/R
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 by using
make prefix=/path/to/here install
More precise control is available at configure time via options: see
configure --help for details.
To install DVI, info and PDF versions of the manuals, use one or more of
make install-dvi
make install-info
make install-pdf
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.
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 95, 98, NT4, 2000, ME and XP (at
least) on Intel x86 and clones (but not on other platforms).
You do need one of those Windows versions: Windows 3.11+win32s will not work.
Your file system must allow long file names (as is likely except perhaps for some network-mounted systems).
Installation is via the installers rw1091.exe
or miniR.exe. Just double-click on the icon and follow the
instructions. You can uninstall R from the Control Panel.
See the R Windows FAQ for more details.
If you want to build this port from the sources, see the file
src/gnuwin32/INSTALL in the source distribution. You will need
to collect, install and test an extensive set of tools: see
http://www.murdoch-sutherland.com/Rtools/ for the current locations.
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 commands window at a directory whose
path does not contain spaces, and run something like
tar zxvf R-1.9.1.tgz
cd R-1.9.1\src\gnuwin32
make
sit back and wait (for about 5 minutes on 1GHz PIII with a fast local disc).
For further details, including how to make the documentation and how to
cross-compile, see src/gnuwin32/INSTALL.
The bin/macosx directory of a CRAN site contains
binaries for a base distribution and a large number of add-on packages
from CRAN to run on Mac OS X version 10.2.0 or higher.
The simplest way is to use R.dmg.sit. Just double-click on the
icon and the archive will be expanded as an image di file. 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. Than you have to expand the R sources and configure R appropriately, for example
tar zxvf R-1.9.1.tgz
cd R-1.9.1
./configure --with-blas='-framework vecLib' --with-lapack --with-aqua
make
sit back and wait. The last option --with-aqua is needed only if you want a Console GUI.
The first two options are strongly recommended.
R is by default configured 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.
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().
Packages may be distributed in source form or compiled binary form. Installing source packages requires that compilers and tools (including Perl 5.004 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.
To install packages from source on 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: .Renviron is not read by R CMD.)
The same command works in Windows if you have the source-code package files installed.
Alternatively, packages can be downloaded and installed from within
R. First set the option CRAN to your nearest CRAN
mirror, for example
> options(CRAN = "http://cran.us.r-project.org/")
Then download and install package foo by
> install.packages("foo")
Unless the library is specified (argument lib) the first library
in the library search path is used.
What this does is different on Unix and Windows. On Unix it consults
the list of available source packages on CRAN, downloads the
latest version of the foo sources, and installs it (via R
CMD INSTALL). On Windows it looks at the list of binary
versions of packages and downloads the latest version (if any).
On Windows install.packages can also install a binary package
from a local zip file by setting argument CRAN to
NULL. RGui.exe has a menu Packages with a GUI
interface to install.packages, update.packages and
library.
On Mac OS X install.packages works as it does on other Unix
systems, but there is an additional function install.binaries
that will download and install binary packages from
CRAN. These Macintosh binary package files have the
extension tgz. The Aqua GUI provides for installation of either
binary or source packages, from CRAN or local files.
The command update.packages() is the simplest way to ensure that
all the packages on your system are up to date. Set the CRAN
option 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 CRAN.
An alternative way of 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 (CRAN, local archive, ...). The print and
summary methods give an overview of installed and available
packages, the upgrade method offers to fetch and install outdated
packages. This allows R to fetch packages from several repositories and
keep in sync with all of them, instead of only one CRAN mirror, and is
intended to become the default package manager for future versions of R.
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: whereas it is currently possible to install package bundles, one cannot remove these as such--the packages contained in the bundle have to removed individually.
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.
Unless you do not want to view graphs on-screen you need X11
installed, including its headers and client libraries. (On RedHat Linux
this means the XFree86-devel and XFree86-libs RPMs, for
example.)
You will need Perl version 5.004 or later, available via http://www.perl.com/CPAN/, to build any of the on-line documentation.
You will not be able to build the info files unless you have
makeinfo version 4 or later installed.
The typeset documentation needs tex and latex, or
pdftex and pdflatex.
The command-line editing depends on the readline library
available from any GNU mirror: you will need a fairly recent version.
The bitmapped graphics devices jpeg() and png() 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) respectively.
The bitmap and dev2bitmap devices make use of ghostscript
(http://www.cs.wisc.edu/~ghost).
If you have them installed (including the appropriate headers and of
late enough versions), zlib, libbz2 and PCRE will be used
if specified by --with-zlib, --with-bzlib or
--with-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.
The tcltk package needs Tcl/Tk installed: the sources are available at http://www.scriptics.com/. To specify the locations of the Tcl/Tk files you may need the configuration options
--with-tcltk
--with-tcl-config=TCL_CONFIGtclConfig.sh
--with-tk-config=TK_CONFIGtkConfig.sh
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.
Versions of Tcl/TK from 8.3 to 8.4.4 have been used successfully: 8.0 is no longer supported.
The linear algebra routines in R can make use of enhanced BLAS (Basic
Linear Algebra Subprograms, http://www.netlib.org/blas/faq.html)
routines. Some are compiler-system-specific (libsunperf on Sun
Sparc1, libessl on IBM, vecLib on Mac OS
X) but ATLAS (http://math-atlas.sourceforge.net/) is a "tuned"
BLAS that runs on a wide range of Unix-alike platforms. If no more
specific library is found, a libblas library in the library path
will be used. 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. (Alternatively,
the environment variable BLAS_LIBS can be set, for example in
config.site.)
For systems with multiple processors it is possible to use a
multi-threaded version of ATLAS. (Prior to R 1.8.0 this was not
supported since SIGINT signals sent to the process and handled by
the wrong thread could result in segfaults.) A remaining issue is that
R profiling, which uses the SIGPROF signal, may cause
problems. You may want to disable profiling if you use a multi-threaded
version of ATLAS. You can use a multi-threaded ATLAS by specifying
--with-blas="-lptf77blas -lpthread -latlas"
Another tuned BLAS which is available for some processors under Linux is by Kazushige Goto, currently available at http://www.cs.utexas.edu/users/flame/goto/. Once this is is installed, it can be used by one of
--with-blas=goto
--with-blas=-lgoto
Multi-threaded versions of Goto's BLAS are available, so please note the
caveat in the previous paragraph.
For Intel processors under Linux, Intel's Math Kernel Library http://www.intel.com/software/products/mkl/ can be used by
--with-blas="-lmkl -lguide -lpthread"
with the same caveat on multi-threading. (Thanks to Andy Liaw for the
information.)
Note that the BLAS library will be used for several add-on packages as well as for R itself. This means that it is better to use a shared BLAS library, as most of a static library will be compiled into the R executable and each BLAS-using package. In any case, the BLAS library must be usable with dynamically-loadable code: this can be a problem with ATLAS that is not by default built with position-independent code.
You will need double-precision and double-complex versions of the BLAS, but not single-precision nor complex routines.
Provision is made for using an external LAPACK library, principally to
cope with BLAS libraries which contain a copy of LAPACK (such as
libsunperf on Solaris and vecLib on Mac OS X).
However, the likely performance gains are thought to be small (and may
be negative), and the default is not to search for a suitable LAPACK
library. You can specify a specific LAPACK library or a search for a
generic library by the configuration option --with-lapack. The
default for --with-lapack is to check the BLAS library and then
look for an external library -llapack. Sites searching for the
fastest possible linear algebra may want to build a LAPACK library using
the ATLAS-optimized subset of LAPACK. To do so specify something like
--with-lapack="-L/path/to/libs -llapack -lcblas"
since the ATLAS subset of LAPACK depends on libcblas. A value
for --with-lapack can be set via the environment variable
LAPACK_LIBS, but this will only be used if --with-lapack
is specified (as the default value is no) and the BLAS library
does not contain LAPACK.
If you do use --with-lapack, be aware of potential problems
with bugs in the LAPACK 3.0 sources (or in the posted corrections to those
sources). In particular, bugs in DGEEV and DGESDD have
resulted in error messages such as
DGEBRD gave error code -10
(from the Debian -llapack which was current in late 2002). Other
potential problems are incomplete versions of the libraries: for example
libsunperf from Sun Forte 6.x was missing the entry point for
DLANGE and vecLib has omitted the BLAS routine
LSAME.
As with all libraries, you need to ensure that they and R were
compiled with compatible compilers and flags. For example, this means
that on Sun Sparc using the native compilers the flag -dalign
is needed so libsunperf can be used.
An ATLAS `tuned' BLAS can also be used on Windows: see
src/gnuwin32/INSTALL for how to enable this when building from
source, and R Windows FAQ for adding pre-compiled support to binary versions.
Goto's BLAS can also be used when building from source.
Note that under Unix (but not under Windows) if R is compiled against a non-default BLAS, then all BLAS-using packages must also be. So if R is re-built after ATLAS is installed, then packages such as quantreg will need to be re-installed.
configure has many options: running
./configure --help
will give a list. Probably the most important ones not covered elsewhere are (defaults in brackets)
--with-x
--x-includes=DIR--x-libraries=DIR--with-readline
--enable-R-profiling
Rprof() [yes]
--enable-R-shlib
You can use --without-foo or --disable-foo for the
negatives.
You will want to use --disable-R-profiling if you are building
a profiled executable of R (e.g. with -pg).
Flag --enable-R-shlib causes the make process to build R as a
shared library, typically called libR.so, and to take
considerably longer, so you probably only want this if you will be using
an application which embeds R.
If you need or want to set certain configure variables to something
other than their default, you can do that by either editing the file
config.site (which documents all the variables you might want to
set) or on the command line as
./configure VAR=value
If you are building in a directory different from the sources, there can
be copies of config.site in the source and the build directories,
and both will be read (in that order). To force a single file to be
read, set the environment variable CONFIG_SITE to the location of
the file.
These variables are precious, implying that they do not have to be exported to the environment, are kept in the cache even if not specified on the command line and checked for consistency between two configure runs (provided that caching is used), and are kept during automatic reconfiguration as if having been passed as command line arguments, even if no cache is used.
See the variable output section of configure --help for a list of
all these variables.
One common variable to change is R_PAPERSIZE, which defaults to
a4, not letter. (Valid values are a4,
letter, legal and executive.)
If you have libraries and header files, e.g., for GNU readline, in
non-system directories, use the variables LDFLAGS (for libraries,
using -L flags to be passed to the linker) and CPPFLAGS
(for header files, using -I flags to be passed to the C/C++
preprocessors), respectively, to specify these locations. These default
to /usr/local/lib and /usr/local/include to catch the most
common cases. If libraries are still not found, then maybe your
compiler/linker does not support re-ordering of -L and
-l flags (this has been reported to be a problem on HP-UX with
the native cc). In this case, use a different compiler (or a
front end shell script which does the re-ordering).
Another precious variable is R_BROWSER, the default browser, which
should take a value of an executable in the user's path or specify
a full path.
If you find you need to alter configure variables, it is worth noting
that some settings may be cached in the file config.cache, and it
is a good idea to remove that file (if it exists) before re-configuring.
Note that caching is turned off by default: use the command line
option --config-cache (or -C) to enable caching.
To compile R, you will most likely find it easiest to use GNU
make. On Solaris 2.6/7/8 in particular, you need a version of
GNU make different from 3.77; 3.79.1 works fine, as does the Sun
make. The native make is reported to fail on SGI
Irix 6.5 and Alpha/OSF1 (aka Tru64).
To build in a separate directory you need a make that uses the
VPATH variable, for example GNU make, or Sun
make on Solaris 2.7/8/9 (but not earlier).
If you want to use a make by another name, for example if your
GNU make is called gmake, you need to set the variable
MAKE at configure time, for example
./configure MAKE=gmake
To compile R, you need a FORTRAN compiler or f2c, the
FORTRAN-to-C converter (http://www.netlib.org/f2c). The default
is to search for g77, f77, xlf,
frt, pgf77, fl32, af77,
fort77, f90, xlf90, pgf90,
epcf90, f95, fort, xlf95,
lf95, g95, and fc (in that
order)2, and
then for f2c, and use whichever is found first; if none is
found, R cannot be compiled. The search mechanism can be changed
using the configure variables F77 and F2C which specify
the commands that run the FORTRAN 77 compiler and FORTRAN-to-C
converter, respectively. If F77 is given, it is used to compile
FORTRAN; otherwise, if F2C is given, f2c is used even if a
FORTRAN compiler would be be available. If your FORTRAN compiler is in
a non-standard location, you should set the environment variable
PATH accordingly before running configure, or use the
configure variable F77 to specify its full path.
If your FORTRAN libraries are in slightly peculiar places, you should
also look at LD_LIBRARY_PATH or your system's equivalent to make
sure that all libraries are on this path.
You must set whatever compilation flags (if any) are needed to ensure
that FORTRAN integer is equivalent to a C int pointer and
FORTRAN double precision is equivalent to a C double
pointer. This is checked during the configuration process.
Some of the FORTRAN code makes use of COMPLEX*16 variables, which
is a FORTRAN 90 extension. This is checked for at configure
time3, but you may need to avoid
compiler flags4 asserting
FORTRAN 77 compliance.
For performance reasons5 you may want to choose a FORTRAN 90/95 compiler.
If you use f2c you may need to ensure that the FORTRAN type
integer is translated to the C type int. Normally
f2c.h contains typedef long int integer;, which will work
on a 32-bit platform but not on a 64-bit platform.
A wide range of flags can be set in the file config.site or as
configure variables on the command line. We have already mentioned
CPPFLAGS
-I) and any other miscellaneous
options for the C and C++ preprocessors and compilers
LDFLAGS
-L), stripping (-s) and any other miscellaneous
options for the linker
and others include
CFLAGS
MAIN_CFLAGS
SHLIB_CFLAGS
FFLAGS
MAIN_FFLAGS
SHLIB_FFLAGS
MAIN_LDFLAGS
SHLIB_LDFLAGS
Library paths specified as -L/lib/path in LDFLAGS are
collected together and prepended to LD_LIBRARY_PATH (or your
system's equivalent), so there should be no need for -R or
-rpath flags.
To compile a profiling version of R, one might for example want to
use MAIN_CFLAGS=-pg, MAIN_FFLAGS=-pg,
MAIN_LDFLAGS=-pg on platforms where -pg cannot be used
with position-independent code.
Beware: it may be necessary to set CFLAGS and
FFLAGS in ways compatible with the libraries to be used: one
possible issue is the alignment of doubles, another is the way
structures are passed.
This interface is experimental and incomplete. It provides a console
and two graphics devices named gtk() and gnome(). The
console offers a basic command line editing and history mechanism, along
with tool and button bars that give a point-and-click interface to some
R commands. Many of the features of the console are currently
stubs. The gtk() graphics device is a port of the x11()
device to GDK (the GIMP Drawing Kit). The gnome()
device uses the GNOME canvas.
Due to its experimental nature, the GNOME interface for R
will not be built automatically. You must specify it by running
configure with the --with-gnome option. For example, you might
run
./configure --with-gnome
but please check you have all the requirements first. You need at least the following libraries (or later) installed
audiofile-0.2.1
esound-0.2.23
glib-1.2.10
gtk+-1.2.10
imlib-1.9.10
ORBit-0.5.12
gnome-libs-1.4.1.2
libxml-1.8.16
libglade-0.17
It is preferable to have a complete installation of the GNOME desktop environment. If you use Linux, then this should be provided with your distribution. In addition, packaged binary distributions of GNOME are available from http://www.ximian.com for the most popular Linux distributions and for Solaris.
Remember that some package management systems (such as RPM and
deb) make a distinction between the user version of a package and the
developer version. The latter usually has the same name but with the
extension -devel. If you use a pre-packaged version of
GNOME then you must have the developer versions of the above
packages in order to compile the R-GNOME interface.
The full list of GNOME options to configure is
--with-gnome
--with-gnome-includes=DIR--with-gnome-libs=DIR--with-libglade-config=LIBGLADE_CONFIGlibglade-config
This section provides some notes on building R on different Unix-like platforms. These notes are based on tests run on one or two systems in each case with particular sets of compilers and support libraries. Success in building R depends on the proper installation and functioning of support software; your results may differ if you have other versions of compilers and support libraries.
Linux is the main development platform for R, so compilation from the sources is normally straightforward.
Remember that some package management systems (such as RPM and
deb) make a distinction between the user version of a package and the
developer version. The latter usually has the same name but with the
extension -devel or -dev: you need both versions
installed. So please check the configure output to see if the
expected features are detected: if for example readline is
missing add the package containing its headers.
When R has been installed from a binary distribution there are
sometimes problems with missing components such as the Fortran
compiler. Searching the R-help archives will normally reveal
what is needed.
It seems that the gcc compilers normally produce PIC code on
ix86 Linux but do not necessarily do so on 64-bit versions such
as that for AMD Opteron. So care can be needed with BLAS libraries and
when building R as a shared library to ensure that
position-independent code is used in any static libraries (such as the
Tcl/Tk libraries, libpng, libjpeg and zlib) which
might be linked against. Fortunately these are normally built as shared
libraries with the exception of the ATLAS BLAS libraries.
You can build R as a Unix application on Mac OS X using the Apple
Developer Tools and f2c or g77. You will also
need to install an X sub-system or configure with
--without-x. The X window manager is part of the standard Mac
OS X distribution since Mac OS X version 10.3 (Panther).
For more information on how to find these tools please read the R for Mac OS X FAQ.
If you use the X window manager and prefer Terminal.app to
xterm, you should be aware that R, like many Unix tools,
uses the existence of a DISPLAY environment variable to
determine whether an X system is running. This affects the default
graphics device for the commmand line version of R and the behaviour
of the png() and jpeg devices.
The vecLib library of Mac OS X >= 10.2.2 can be used via the
configuration options
--with-blas="-framework vecLib" --with-lapack
to provide higher-performance versions of the BLAS and LAPACK
routines. With gcc 3.1 that appears to be the only way to
build R, as the Fortran support routines in libg2c cannot be
linked into a dynamic library. (We have had reports of success and of
failure with gcc 3.3.)
R has been built successfully on Solaris 8 aka Solaris 2.8 aka SunOS
5.8 using gcc/g77 and the SunPro WorkShop 6 (aka
Forte 6) compilers and the `Sun ONE Studio 7 Compiler Suite' (aka Forte
7), and less regularly on Solaris 2.5.1, 2.6, 2.7 and 9. GNU
make is needed prior to Solaris 2.7 for building other than in
the source tree, and perhaps even then.
The Solaris versions of several of the tools needed to build R
(e.g. make, ar and ld) are in
/usr/ccs/bin, so if using those tools ensure this is in your
path.
gcc 3.2.1 and 3.2.2 generate incorrect code on 32-bit Solaris
builds with optimization, but versions 3.1, 3.2, 3.2.3 and later work
correctly. At least files src/main/engine.c,
src/main/graphics.c and src/modules/devX11.c are affected.
If using gcc, do ensure that the compiler was compiled for the
version of Solaris in use. (This can be ascertained from gcc
-v.) gcc makes modified versions of some header files, and
so (for example) gcc compiled under Solaris 2.6 will not
compile R under Solaris 2.7. Also, do ensure that it was compiled
for the assembler/loader in use. If you download gcc from
http://www.sunfreeware.com then you need to download
binutils too. To avoid all these pitfalls we strongly
recommended you compile gcc from the sources yourself.
When using the SunPro compilers do not specify -fast, as
this disables IEEE arithmetic and make check will
fail. The maximal set of optimization options known to work is
-xlibmil -xO5 -dalign
We have found little performance difference between gcc and
cc but considerable benefit from using a SunPro Fortran
compiler: the gcc/f77 combination works well. For
many C++ applications (e.g. package Matrix) Forte 7 requires
-lCstd, which the configure script will add to
SHLIB_CXXLDFLAGS if it identifies the compiler correctly.
To compile for a 64-bit target on Solaris (which needs an UltraSparc chip and for support to be enabled in the OS) with the Forte 6 and 7 compilers we used
CC="cc -xarch=v9"
CFLAGS="-xO5 -xlibmil -dalign"
F77="f95 -xarch=v9"
FFLAGS="-xO5 -xlibmil -dalign"
CXX="CC -xarch=v9"
CXXFLAGS="-xO5 -xlibmil -dalign"
in config.site.
For 64-bit compilation with gcc 3.2.x and later we used
CC="gcc -m64"
FFLAGS="-m64 -g -O2"
CXXFLAGS="-m64 -g -O2"
LDFLAGS="-L/usr/local/lib/sparcv9 -L/usr/local/lib"
Note that /usr/local/lib/sparcv9 will need to be in the
LD_LIBRARY_PATH during configuration.
Note that using f95 allows the Sun performance library
libsunperf to be selected: it will not work with f77,
nor with g77. libsunperf contains both BLAS and LAPACK
code, and --with-lapack is recommended for 32-bit builds using
f95, but not for 64-bit builds where on our test system it
failed in both Forte 6U1 and 7, albeit in different ways. Our
experience has been that ATLAS's BLAS is faster than libsunperf,
especially for complex numbers.
Some care is needed to ensure that libraries found by
configure are compatible with the R executable and modules, as
the testing process will not detect many of the possible problems. For
32-bit builds under cc the flag -dalign is needed for
some of the Sun libraries: fortunately the equivalent flag for
gcc, -mno-unaligned-doubles, is the default. In
theory, libraries such as libpng, libjpeg, zlib and
the ATLAS libraries need to be built with a pic or PIC
flag, which could be a problem if static libraries are used. In
practice this seems to give little problem for 32-bit builds.
For a 64-bit build, 64-bit libraries must be used. As the configuration
process by default sets LDFLAGS to -L/usr/local/lib,
you may need to set it to avoid finding 32-bit addons (as in the
gcc -m64 example above). It is possible to build Tcl/Tk as
64-bit libraries with the configure option --enable-64bit, but
only with the Forte compiler (and not with gcc) as of Tcl/Tk 8.4.5.
R has been built successfully on HP-UX 10.2 and HP-UX 11.0 using both
native compilers and gcc. However, 10.2 has not been tested
since R 1.4.0. By default, R is configured to use gcc and
g77 on HP-UX (if available). Some installations of
g77 only install a static version of the g2c library
that cannot be linked into a shared library since its files have not
been compiled with the appropriate flag for producing position
independent code (PIC). This will result in make
failing with a linker error similar to
ld: CODE_ONE_SYM fixup to non-code subspace in file foo.o -
shared library must be position independent. Use +z or +Z to recompile.
(+z and +Z are the PIC flags for the native
compiler cc.) If this is the case you either need to modify
your g77 installation or configure with
F77=fort77
to specify use of the native POSIX-compliant FORTRAN 77 compiler.
You may find that configure detects other libraries that R
needs to use as shared libraries but are only available as static
libraries. If you cannot install shared versions you will need to tell
configure not to use these libraries, or make sure they are
not in the library path. The symptom will the linker error shown in the
last paragraph. Static libraries that might be found and would cause
problems are
BLAS use --without-blas
Tcl/Tk use --without-tcltk
GNOME not built by default
libpng use --without-libpng
jpeg use --without-jpeglib
zlib use --without-zlib
and bzip2 and pcre are problematic when building
libR.so, only. These can be avoided by --without-bzlib
and --without-pcre respectively, but these are the defaults.
Some versions of gcc may contain what appears to be a bug at
the -O2 optimization level that causes
> 2 %/% 2
[1] 1
> 1:2 %/% 2
[1] 0 0 # wrong!!
which will cause make check to fail. If this is the case, you
should use CFLAGS to specify -O as the optimization
level to use.
Some systems running HP-UX 11.0 may have a gcc that was
installed under HP-UX 10.2. Between versions 10.2 and 11.0 HP-UX
changed its support functions for IEEE arithmetic from the
recommended functions of the IEEE standard to the ones
specified in the C9x draft standard. In particular, this means that
finite has been replaced by isfinite. A gcc
configured for HP-UX 10.2 run on 11.0 will not find isfinite, and
as a result configure does not recognize the machine as fully
supporting IEEE arithmetic and does not define IEEE_754
when compiling C code. This results in a failure in make
check. The best solution is to install a properly configured
gcc. An alternative work-around is to add -DIEEE_754
to the CFLAGS variable.
You can configure R to use both the native cc and
fort77 with
./configure CC=cc F77=fort77
f90 insists on linking against a static libF90.a which
typically resides in a non-standard directory (e.g.,
/opt/fortran90/lib). Hence, to use f90 one needs to
add this directory to the linker path via the configure variable
LDFLAGS (e.g., ./configure F77=f90
LDFLAGS=/opt/fortran90/lib).
R has been built successfully on IRIX64 6.5 using
gcc/f77 or cc/f77 for 32-bit
executables and the native compilers for a 64-bit executable. The
command
./configure CC="cc -64" F77="f77 -64" --with-tcltk=no
was used to create the 64-bit executable. It was necessary to
explicitly omit Tcl/Tk because configure would find the 32-bit
version but not detect that is was incompatible with a 64-bit build.
A 32-bit build using gcc/g77 passed make
check but failed make test-all-extras in the complex LAPACK
tests.
George N. White III reports that the strptime tests in 1.9.0 fail
on IRIX 6.5 systems prior to 6.5.22m (e.g. 6.5.19m and 6.5.21m) unless
Arthur Olson's timezone data ftp://elsie.nci.nih.gov/pub/ (see
also http://cspry.co.uk/computing/Indy_admin/TIMEZONE.html) are
installed and -ltz is added to the list of libraries (for
example, in environment variable LIBS).
R has been built successfully on an Alpha running OSF1 V4.0 using
gcc/g77 and cc/f77. Mixing
cc and g77 fails to configure. The
configure option --without-blas was used since the
native blas seems not to have been built with the flags needed to
suppress SIGFPE's. Currently R does not set a signal handler for
SIGFPE on platforms that support IEEE arithmetic, so
these are fatal.
Attempts to build R on an Alpha with FreeBSD 4.3 have been only
partly successful. Configuring with -mieee added to both
CFLAGS and FFLAGS builds successfully, but tests fail with
SIGFPE's. It would appear that -mieee only defers these
rather than suppressing them entirely. Advice on how to complete this
port would be greatly appreciated.
On AIX 4.3.3 and AIX 5.1, it was found that the use of "run time
linking" (as opposed to normal AIX style linking) was required. For
this, the R main program must be linked to the runtime linker with
the -brtl linker option, and shareable objects must be enabled
for runtime linking with the -G linker option. Without these
options, the AIX linker would not automatically link to any shared
object with a .so extension. Also, the R main program would
be unable to dynamically load modules (such as X11) with the
dlopen call.
When setting MAIN_LDFLAGS and SHLIB_LDFLAGS accordingly,
note that linker flags must be escaped using -Wl, if
gcc is used for linking: use MAIN_LDFLAGS="-Wl,brtl"
and SHLIB_LDFLAGS="-Wl,-G" in this case.
Harald Servat Gelabert <harald at cepba dot upc dot es> reported success building R 1.7.0 under AIX 5.1 with
CC=xlc
F77=xlf
CXX=xlC
CFLAGS=-O3 -qstrict -qmaxmem=8192
FFLAGS=-O3 -qstrict -qmaxmem=8192
CXXFLAGS=-O2 -qmaxmem=8192
MAIN_LDFLAGS=-Wl,-brtl
SHLIB_LDFLAGS=-Wl,-G
but was unable to use the X libraries or the native BLAS (ESSL) and so
used --without-x --without-blas.
Tim Hoar <thoar at cgd dot ucar dot edu> reported success building R 1.9.0 under AIX 5.1 in 64-bit mode with
OBJECT_MODE=64
CC=/usr/bin/xlc_r
F77=/usr/bin/xlf_r
CXX=/usr/bin/xlC_r
LDFLAGS='-brtl'
CFLAGS='-O -qstrict'
FFLAGS='-O -qstrict'
CXXFLAGS='-O -qstrict'
and the X11() device worked. His system required the
Makeconf file to be edited to replace /lib/crt0.o by
/lib/crt0_64.o in R_XTRA_LIBS, and configure now
tries to detect this.
There is a search engine available from the front page of the
HTML help system, the page that is displayed by
help.start(). The search engine is written in Java and invoked
by Javascript code, so the first thing to do is to ensure that both are
enabled in your favourite browser. Then try it and see: with most
browsers you should see
Applet SearchEngine started
displayed in the status bar. (Internet Explorer shows Applet
started.) Then click on one of the keywords and after a short delay
(several seconds) you should see a page of search results.
If this fails you should double-check that Java is enabled in your browser by visiting a page such as http://www.java.com/en/download/help/testvm.jsp (although that will fail for earlier versions of Java such as the Microsoft JVM which do work with R). You can check which version of Java is in use at http://java.sun.com/docs/books/tutorial/applet/practical/properties.html. Java 1.1 is sufficent.
Many thanks to Marc Schwartz in tracking down many of these issues with enabling the Java search engine.
We are aware of problems with certain Java installations. In
particular, Sun's Java Run-time Environment j2re 1.4.2_02 does
not work under Linux. Current browsers of the Mozilla family (including
Mozilla >= 1.4, Netscape 7.1 and FireFox) are compiled under gcc
3.x and require the ns610-gcc32 version of the Java
plugin that was introduced with j2re 1.4.2, so the only Java
version that we know to work is j2re 1.4.2_01. Marc Schwartz has
kindly made Linux i586 distributions available: see
http://www.MedAnalytics.com/INSTALL
Other Java installations, for example those from Blackdown and IBM, have been used.
Other useful links are for Mozilla, http://plugindoc.mozdev.org/faqs/java.html and http://www.mozilla.org/releases/mozilla1.6/installation-extras.html, for Konqueror http://www.konqueror.org/javahowto/, for Opera http://www.opera.com/support/search/supsearch.dml?index=459 and for Debian GNU/Linux http://www.debian.org/doc/manuals/debian-java-faq/.
We have much less experience, but we do know that Sun's Run-time
Environment j2re 1.4.2_03 does not work under Solaris, whereas
j2re 1.4.2_01 and earlier do. Marc Schwartz kindly made Solaris
distributions of j2re 1.4.2_01 available: see
http://www.MedAnalytics.com/INSTALL
We have not seen any problems on Windows provided a Java Virtual Machine
has been installed and is operational: Sun's current j2re
1.4.2_04 works in Internet Explorer, Netscape 7.1, Mozilla 1.6 and
Mozilla FireFox 0.8 on Windows XP. Note that a recent Windows system
may not have Java installed at all. For Netscape/Mozilla/FireFox visit
http://java.sun.com/getjava/manual.html to install a Sun JVM.
Which (if any) JVM is enabled can be set in `Set Program Access and
Defaults' in Windows XP (SP1 or later), and which JVM is used by browser
plugins may also be controlled by the Sun Java applet in the Control
Panel.
The HTML search engine does not work with Safari under Mac OS X, and
Sun's j2re 1.4.x is said not to work with Mozilla 1.6.
The Aqua GUI provides an interface to help.search that may
substitute for the Java search.
There are a number of sources of problems when installing R on a new hardware/OS platform. These include
Floating Point Arithmetic: R supports the POSIX,
SVID and IEEE models for floating point arithmetic. The
POSIX and SVID models provide no problems. The IEEE
model however can be a pain. The problem is that there is no agreement
on how to set the signalling behaviour; Sun/Sparc, SGI/IRIX and ix86
Linux require no special action, FreeBSD requires a call to (the macro)
fpsetmask(0) and OSF1 requires that computation be done with a
-ieee_with_inexact flag etc. On a new platform you must find
out the magic recipe and add some code to make it work. This can often
be done via the file config.site which resides in the top level
directory.
Beware of using high levels of optimization, at least initially. On
many compilers these reduce the degree of compliance to the
IEEE model. For example, using -fast on the Solaris
SunPro compilers causes R's NaN to be set incorrectly.
Shared Libraries: There seems to be very little agreement
across platforms on what needs to be done to build shared libraries.
there are many different combinations of flags for the compilers and
loaders. GNU libtool cannot be used (yet), as it currently does not
fully support FORTRAN (and will most likely never support f2c:
one would need a shell wrapper for this). The technique we use is to
first interrogate the X window system about what it does (using
xmkmf), and then override this in situations where we know
better (for tools from the GNU Compiler Collection and/or platforms we
know about). This typically works, but you may have to manually
override the results. Scanning the manual entries for cc and
ld usually reveals the correct incantation. Once you know the
recipe you can modify the file config.site (following the
instructions therein) so that the build will use these options.
It seems that gcc 3.4.0 on ix86 Linux defeats attempts by
the LAPACK code to avoid computations entirely in extended-precision
registers, so file src/modules/lapack/dlamc.f may need to
compiled without optimization. If configure detects GNU Fortran it adds
flag -ffloat-store which suffices, but it is possible that
src/modules/lapack/Makefile will need to be edited to remove
optimization on other platforms.
If you do manage to get R running on a new platform please let us know about it so we can modify the configuration procedures to include that platform.
If you are having trouble getting R to work on your platform please feel free to get in touch to ask questions. We have had a fair amount of practice at porting R to new platforms ....
configure: Using make, Configuration variables, Installation, Simple compilation
install.packages: Installing packages
make: Using make
R_HOME: Simple compilation
remove.packages: Removing packages
rsync: Using rsync
update.packages: Updating packages
Using the SunPro aka Forte aka Sun ONE cc and
f95 compilers
On HP-UX fort77 is the POSIX
compliant FORTRAN compiler, and comes second in the search list.
as well as its equivalence to the Rcomplex
structure defined in R_ext/Complex.h.
In particular, avoid g77's
-pedantic, which gives confusing error messages.
e.g., to use an optimized BLAS on Sun/Sparc