Chapter 12 Appendix C Platform notes

This section provides some notes on building R on different Unix-alike 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.

Older versions of this manual (for R < 2.10.0) contain notes on platforms such as HP-UX, IRIX and Alpha/OSF1 for which we have had no recent reports.

C macros to select particular platforms can be tricky to track down (there is a fair amount of misinformation on the Web). The Wiki (currently) at http://sourceforge.net/p/predef/wiki/Home/ can be helpful. The R sources have used (often in included software under src/extra)

AIX: _AIX
Cygwin: __CYGWIN__
FreeBSD: __FreeBSD__
HP-UX: __hpux__, __hpux
IRIX: sgi, __sgi
Linux: __linux__
macOS: __APPLE__
NetBSD: __NetBSD__
OpenBSD: __OpenBSD__
Solaris: __sun, sun
Windows: _WIN32, _WIN64

C.1 X11 issues

The ‘X11()’ graphics device is the one started automatically on Unix-alikes when plotting. As its name implies, it displays on a (local or remote) X server, and relies on the services provided by the X server.

The ‘modern’ version of the ‘X11()’ device is based on ‘cairo’ graphics and (in most implementations) uses ‘fontconfig’ to pick and render fonts. This is done on the server, and although there can be selection issues, they are more amenable than the issues with ‘X11()’ discussed in the rest of this section.

When X11 was designed, most displays were around 75dpi, whereas today they are of the order of 100dpi or more. If you find that X11() is reporting⁶³ missing font sizes, especially larger ones, it is likely that you are not using scalable fonts and have not installed the 100dpi versions of the X11 fonts. The names and details differ by system, but will likely have something like Fedora’s

xorg-x11-fonts-75dpi
xorg-x11-fonts-100dpi
xorg-x11-fonts-ISO8859-2-75dpi
xorg-x11-fonts-Type1
xorg-x11-fonts-cyrillic

and you need to ensure that the ‘-100dpi’ versions are installed and on the X11 font path (check via xset -q). The ‘X11()’ device does try to set a pointsize and not a pixel size: laptop users may find the default setting of 12 too large (although very frequently laptop screens are set to a fictitious dpi to appear like a scaled-down desktop screen).

More complicated problems can occur in non-Western-European locales, so if you are using one, the first thing to check is that things work in the C locale. The likely issues are a failure to find any fonts or glyphs being rendered incorrectly (often as a pair of ASCII characters). X11 works by being asked for a font specification and coming up with its idea of a close match. For text (as distinct from the symbols used by plotmath), the specification is the first element of the option “X11fonts” which defaults to

"-adobe-helvetica-%s-%s-*-*-%d-*-*-*-*-*-*-*"

If you are using a single-byte encoding, for example ISO 8859-2 in Eastern Europe or KOI8-R in Russian, use xlsfonts to find an appropriate family of fonts in your encoding (the last field in the listing). If you find none, it is likely that you need to install further font packages, such as ‘xorg-x11-fonts-ISO8859-2-75dpi’ and ‘xorg-x11-fonts-cyrillic’ shown in the listing above.

Multi-byte encodings (most commonly UTF-8) are even more complicated. There are few fonts in ‘iso10646-1’, the Unicode encoding, and they only contain a subset of the available glyphs (and are often fixed-width designed for use in terminals). In such locales fontsets are used, made up of fonts encoded in other encodings. If the locale you are using has an entry in the ‘XLC_LOCALE’ directory (typically /usr/share/X11/locale), it is likely that all you need to do is to pick a suitable font specification that has fonts in the encodings specified there. If not, you may have to get hold of a suitable locale entry for X11. This may mean that, for example, Japanese text can be displayed when running in ‘ja_JP.UTF-8’ but not when running in ‘en_GB.UTF-8’ on the same machine (although on some systems many UTF-8 X11 locales are aliased to ‘en_US.UTF-8’ which covers several character sets, e.g. ISO 8859-1 (Western European), JISX0208 (Kanji), KSC5601 (Korean), GB2312 (Chinese Han) and JISX0201 (Kana)).

On some systems scalable fonts are available covering a wide range of glyphs. One source is TrueType/OpenType fonts, and these can provide high coverage. Another is Type 1 fonts: the URW set of Type 1 fonts provides standard typefaces such as Helvetica with a larger coverage of Unicode glyphs than the standard X11 bitmaps, including Cyrillic. These are generally not part of the default install, and the X server may need to be configured to use them. They might be under the X11 fonts directory or elsewhere, for example,

/usr/share/fonts/default/Type1
/usr/share/fonts/ja/TrueType

C.2 Linux

Linux is the main development platform for R, so compilation from the sources is normally straightforward with the standard compilers and libraries.⁶⁴

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 developer package. (On most systems you will also need ‘ncurses’ and its developer package, although these should be dependencies of the ‘readline’ package(s).) You should expect to see in the configure summary

  Interfaces supported:      X11, tcltk
  External libraries:        readline, curl
  Additional capabilities:   PNG, JPEG, TIFF, NLS, cairo, ICU

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 ‘ix86’ Linux accepts non-PIC code in shared libraries, but this is not necessarily so on other platforms, in particular on 64-bit CPUs such as ‘x86_64’. 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.

The default optimization settings chosen for CFLAGS etc are conservative. It is likely that using -mtune will result in significant performance improvements on recent CPUs (especially for ‘ix86’): one possibility is to add -mtune=native for the best possible performance on the machine on which R is being installed: if the compilation is for a site-wide installation, it may still be desirable to use something like -mtume=core2.⁶⁵ It is also possible to increase the optimization levels to -O3: however for many versions of the compilers this has caused problems in at least one CRAN package.

For platforms with both 64- and 32-bit support, it is likely that

LDFLAGS="-L/usr/local/lib64 -L/usr/local/lib"

is appropriate since most (but not all) software installs its 64-bit libraries in /usr/local/lib64. To build a 32-bit version of R on ‘x86_64’ with Fedora 24 we used

CC="gcc -m32"
CXX="g++ -m32"
F77="gfortran -m32"
FC=${F77}
OBJC=${CC}
LDFLAGS="-L/usr/local/lib"
LIBnn=lib

Note the use of ‘LIBnn’: ‘x86_64’ Fedora installs its 64-bit software in /usr/lib64 and 32-bit software in /usr/lib. Linking will skip over inappropriate binaries, but for example the 32-bit Tcl/Tk configure scripts are in /usr/lib. It may also be necessary to set the pkg-config path, e.g. by

export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

The 32-bit system libcurl did not work with the system CA certificates: this is worked around in R’s test suite.

64-bit versions of Linux are built with support for files > 2Gb, and 32-bit versions will be if possible unless –disable-largefile is specified.

Note that 32-bit glibc currently uses a 32-bit time_t type, so to pass all the date-time checks needs R built with flag –with-internal-tzcode.

To build a 64-bit version of R on ‘ppc64’ (also known as ‘powerpc64’) with gcc 4.1.1, Ei-ji Nakama used

CC="gcc -m64"
CXX="gxx -m64"
F77="gfortran -m64"
FC="gfortran -m64"
CFLAGS="-mminimal-toc -fno-optimize-sibling-calls -g -O2"
FFLAGS="-mminimal-toc -fno-optimize-sibling-calls -g -O2"

the additional flags being needed to resolve problems linking against libnmath.a and when linking R as a shared library.

C.2.1 Clang

R has been built with Linux ‘ix86’ and ‘x86_64’ C and C++ compilers (http://clang.llvm.org) based on the Clang front-ends, invoked by CC=clang CXX=clang++, together with gfortran. These take very similar options to the corresponding GCC compilers.

This has to be used in conjunction with a Fortran compiler: the configure code will remove -lgcc from FLIBS, which is needed for some versions of gfortran.

The current default for clang++ is to use the C++ runtime from the installed g++. Using the runtime from the libc++ project (http://libcxx.llvm.org/, Fedora RPM libcxx-devel) has also been tested: for some R packages only the variant using libcxxabi was successful.

Earlier builds of clang have no OpenMP support, those of versions 3.7.0 or later may.⁶⁶

C.2.2 Intel compilers

Intel compilers have been used under ‘ix86’ and ‘x86_64’ Linux. Brian Ripley used version 9.0 of the compilers for ‘x86_64’ on Fedora Core 5 with

CC=icc
CFLAGS="-g -O3 -wd188 -ip -mp"
F77=ifort
FLAGS="-g -O3 -mp"
CXX=icpc
CXXFLAGS="-g -O3 -mp"
FC=ifort
FCFLAGS="-g -O3 -mp"
ICC_LIBS=/opt/compilers/intel/cce/9.1.039/lib
IFC_LIBS=/opt/compilers/intel/fce/9.1.033/lib
LDFLAGS="-L$ICC_LIBS -L$IFC_LIBS -L/usr/local/lib64"
SHLIB_CXXLD=icpc

configure will add ‘-c99’ to CC for C99-compliance. This causes warnings with icc 10 and later, so use CC=“icc -std=c99” there. The flag -wd188 suppresses a large number of warnings about the enumeration type ‘Rboolean’. Because the Intel C compiler sets ‘GNUC’ without complete emulation of gcc, we suggest adding CPPFLAGS=-no-gcc.

To maintain correct IEC 60559 arithmetic you most likely need add flags to CFLAGS, FFLAGS and CXXFLAGS such as -mp (shown above) or -fp-model precise -fp-model source, depending on the compiler version.

Others have reported success with versions 10.x and 11.x. Bjørn-Helge Mevik reported success with version 2015.3 of the compilers, using (for a SandyBridge CPU on Centos 6.x)

fast="-fp-model precise -ip -O3 -opt-mem-layout-trans=3 -xHost -mavx"
CC=icc
CFLAGS="$fast -wd188"
F77=ifort
FFLAGS="$fast"
CXX=icpc
CXXFLAGS="$fast"
FC=$F77
FCFLAGS=$F77FLAGS

C.3 macOS

(‘macOS’ was known as ‘OS X’ from 2012–2016.)

The instructions here are for ‘x86_64’ builds on 10.11 (El Capitan) or later. R can be built for 10.9 and 10.10 and in principle⁶⁷ for 10.6 to 10.8.

To build R you need Apple’s ‘Command Line Tools’: these can be (re-)installed by xcode-select –install. (If you have a fresh OS installation, running e.g. make in a terminal will offer the installation of the command-line tools. If you have installed Xcode, this provides the command-line tools. The tools will need to be reinstalled when macOS is upgraded, as upgrading partially removes them.)

You need GNU readline⁶⁸ That and other binary components are available from https://r.research.att.com/libs: you will need pcre and xz (for libzma) as recent macOS versions provide libraries but not headers for these (and the system pcre is too old at version 8.02).

An X sub-system is required unless configuring using –without-x: see https://xquartz.macosforge.org/. R’s configure script can be told to look for X11 in XQuartz’s main location of /opt/X11, e.g. by

--x-includes=/opt/X11/include --x-libraries=/opt/X11/lib

although linked versions under /usr/X11 will be found.

To use the quartz() graphics device you need to configure with –with-aqua (which is the default): quartz() then becomes the default device when running R at the console and X11 would only be used for the command-line-R data editor/viewer and one version of Tcl/Tk. (This option needs an Objective-C compiler⁶⁹ which can compile the source code of quartz().)

Use –without-aqua if you want a standard Unix-alike build: apart from disabling quartz() and the ability to use the build with R.APP, it also changes the default location of the personal library (see ?.libPaths).

Various compilers can be used. One could use

CC=clang
CXX=clang++
F77=/usr/local/gfortran/bin/gfortran
FC=$F77
OBJC=clang
CFLAGS='-Wal -g -O2'
CXXFLAGS='-Wall -g -O2'
OBJCFLAGS='-Wall -g -O2'
F77FLAGS='-Wall -g -O2 -mtune=generic'
FCFLAGS=$F77FLAGS

with clang and clang++ from the ‘Command Line Tools’ and the Fortran compiler from one of the packages described in the next paragraph.

There are installers⁷⁰ for Fortran compilers for El Capitan and Sierra at http://coudert.name/software/gfortran-6.1-ElCapitan.dmg and http://coudert.name/software/gfortran-6.3-Sierra.dmg. (These compilers are also available from a CRAN mirror: select ‘Other’ under ‘Software’ from the left-hand menu.) One way to use these builds with a binary distribution of R is to have a ~/.R/Makevars file similar to (El Capitan)

F77 = /usr/local/gfortran/bin/gfortran
FC = $F77
FLIBS = -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0
  -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm

or (Sierra or High Sierra)

F77 = /usr/local/gfortran/bin/gfortran
FC = $F77
FLIBS = -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0
  -L/usr/local/gfortran/lib -lgfortran -lquadmath -lm

(with lines broken here for legibility).

More recent and complete distributions of clang are often available from http://llvm.org/releases/: for example at the time of writing for 4.0.1, built for Sierra or later. In particular, these should include support for OpenMP. Another build of clang 4.0.0 is available at https://r.research.att.com/libs/clang-4.0.0-darwin15.6-Release.tar.gz. Suppose one of these distributions is installed under /usr/local/clang4. Then R could be configured by something like

./configure --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib \
PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig \
DYLD_FALLBACK_LIBRARY_PATH=/usr/local/clang4/lib:/usr/local/lib

with config.site containing

CC=/usr/local/clang4/bin/clang
OBJC=$CC
F77=/usr/local/gfortran/bin/gfortran
FC=$F77
CXX=/usr/local/clang4/bin/clang++
LDFLAGS="-L/usr/local/clang4/lib -L/usr/local/lib"
R_LD_LIBRARY_PATH=/usr/local/clang4/lib:/usr/local/lib

The care to specify library paths is to ensure that the OpenMP runtime library, here /usr/local/clang4/lib/libomp.dylib, is found when needed. If this works, you should see the line

checking whether OpenMP SIMD reduction is supported... yes

in the configure output. Also, ‘R_LD_LIBRARY_PATH’ needs to be set to find the latest version of the C++ run-time libraries rather than the system ones.

Pre-compiled versions of many of the Useful libraries and programs are available from https://r.research.att.com/libs/. You will most likely want at least jpeg and tiff. The pkg-config utility is not provided by Apple and used for the installation from source of many packages: it will also be used if present when configuring the X11() and bitmap devices.

Support for cairo (without Pango) can be enabled if pkg-config and XQuartz are available, Make sure the XQuartz’s pkg-config files are found first on the configuration path: for example by setting

export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

or appending that variable to the configure command.

The Accelerate library can be used via the configuration options

--with-blas="-framework Accelerate" --with-lapack

to provide potentially higher-performance versions of the BLAS and LAPACK routines.⁷¹

Looking at the top of /Library/Frameworks/R.framework/Resources/etc/Makeconf will show the compilers and configuration options used for the CRAN binary package for R: at the time of writing the non-default options

--enable-memory-profiling --enable-R-framework

were used.

Configure option –with-internal-tzcode is the default on macOS, as the system implementation of time zones does not work correctly for times before 1902 or after 2037 (despite using a 64-bit time_t).

The TeX implementation used by the developers is MacTeX (https://www.tug.org/mactex/): the full installation is about 5GB, but a smaller version (‘Basic TeX’) is available at https://www.tug.org/mactex/morepackages.html to which you will need to add some packages, e.g. for the 2017 version we needed to add⁷² cm-super, helvetic, inconsolata and texinfo which brought this to about 310MB. ‘TeX Live Utility’ (available via the MacTeX front page) provides a graphical means to manage TeX packages.

One macOS quirk is that the default path has /usr/local/bin after /usr/bin, contrary to common practice on Unix-alikes. This means that if you install tools from the sources they will by default be installed under /usr/local and not supersede the system versions.

If you upgrade your OS you should re-install the ‘Command Line Tools’ and may need to re-install XQuartz and Java (this has been needed for some upgrades but not others).

C.3.1 High Sierra

Default builds⁷³ of R on High Sierra fail to detect the system time zone, as it gets reported something like

  unknown timezone ‘default/Europe/London’

which is not a standard form. This can be circumvented by setting the environment variable TZ (in the example, to ‘Europe/London’.

C.3.2 Tcl/Tk headers and libraries

If you plan to use the tcltk package for R, you need to install a distribution of Tcl/Tk. There are two alternatives. If you use R.APP you will want to use X11-based Tcl/Tk (as used on other Unix-alikes), which is installed as part of the CRAN binary for R and available as separate tcl and tk components from https://r.research.att.com/libs/. This may need configure options

-with-tcltk=/usr/local/lib

--with-tcl-config=/usr/local/lib/tclConfig.sh 
--with-tk-config=/usr/local/lib/tkConfig.sh

Note that this requires a matching XQuartz installation.

There is also a native (‘Aqua’) version of Tcl/Tk which produces widgets in the native macOS style: this will not work with R.APP because of conflicts over the macOS menu, but for those only using command-line R this provides a much more intuitive interface to Tk for experienced Mac users. Most versions of macOS come with Aqua Tcl/Tk libraries, but these are not at all recent versions of Tcl/Tk (8.5.9 in Sierra, which is not even the latest patched version in that series). It is better to install Tcl/Tk 8.6.x from the sources or a binary distribution from https://www.activestate.com/activetcl/downloads. Configure R with

--with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh 
--with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh

(for the versions bundled with macOS, use paths starting with /System/Library).

If you need to find out which distribution of Tk is in use at run time, use

library(tcltk)
tclvalue(.Tcl("tk windowingsystem"))  # "x11" or "aqua"

C.3.3 Java

The situation with Java support on macOS is messy.⁷⁴ As from R 3.4.0 the CRAN distribution of rJava requires Java 8 (aka 1.8).

macOS no longer comes with an installed Java runtime (JRE), and a macOS upgrade may remove one if already installed: it is intended to be installed at first use. Check if a JRE is installed by running java -version in a Terminal window: if Java is not installed⁷⁵ this should prompt you to install it. You can also install directly the latest Java from Oracle (currently from http://www.oracle.com/technetwork/java/javase/downloads/index.html).

Binary distributions of R are built against a specific version (e.g. 1.8.0_131) of Oracle Java so sudo R CMD javareconf may be needed before using Java-using packages.

To see what compatible versions of Java are currently installed, run /usr/libexec/java_home -V -a x86_64. If needed, set the environment variable JAVA_HOME to choose between these, both when R is built from the sources and when R CMD javareconf is run.

Configuring and building R both looks for a JRE and for support for compiling JNI programs (used by packages rJava and JavaGD); the latter requires a JDK (Java SDK) and not just a JRE.

The build process tries to fathom out what JRE/JDK to use, but it may need some help, e.g. by setting JAVA_HOME. The Oracle JDK can be specified explicitly by something like

JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home
JAVA_CPPFLAGS="-I/${JAVA_HOME}/include -I/${JAVA_HOME}/include/darwin"
JAVA_LD_LIBRARY_PATH="${JAVA_HOME}/jre/lib/server"
JAVA_LIBS="-L/${JAVA_HOME}/jre/lib/server -ljvm"

in config.site.

(An Apple JRE, if available, can be specified explicitly by something like

JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
JAVA_CPPFLAGS="-I/System/Library/Frameworks/JavaVM.framework/Headers"
JAVA_LD_LIBRARY_PATH=
JAVA_LIBS="-framework JavaVM"

Note that it is necessary to set the environment variable NOAWT to 1 to install many of the Java-using packages.

C.3.4 Frameworks

The CRAN build of R is installed as a framework, which is selected by the option

./configure --enable-R-framework

(This is intended to be used with an Apple toolchain: others may not support frameworks correctly but that from llvm.org does.)

It is only needed if you want to build R for use with the R.APP console, and implies –enable-R-shlib to build R as a dynamic library. This option configures R to be built and installed as a framework called R.framework. The default installation path for R.framework is /Library/Frameworks but this can be changed at configure time by specifying the flag –enable-R-framework[=DIR] (or –prefix) or at install time via

make prefix=/where/you/want/R.framework/to/go install

Note that installation as a framework is non-standard (especially to a non-standard location) and Unix utilities may not support it (e.g. the pkg-config file libR.pc will be put somewhere unknown to pkg-config).

C.3.5 Building R.app

Note that building the R.APP GUI console is a separate project, using Xcode. Before compiling R.APP make sure the current version of R is installed in /Library/Frameworks/R.framework and working at the command-line (this can be a binary install).

The current sources can be checked out by

svn co https://svn.r-project.org/R-packages/trunk/Mac-GUI

and built by loading the R.xcodeproj project (select the R target and a suitable configuration), or from the command-line by e.g.

xcodebuild -target R -configuration Release

See also the INSTALL file in the checkout or directly at https://svn.r-project.org/R-packages/trunk/Mac-GUI/INSTALL.

R.APP does not need to be installed in any specific way. Building R.APP results in the R.APP bundle which appears as one R icon. This application bundle can be run anywhere and it is customary to place it in the /Applications folder.

C.4 Solaris

R has been built successfully on Solaris 10 using the (zero cost) Oracle Developer Studio⁷⁶ compilers: there has been some success with gcc/gfortran. (Recent Sun machines are AMD Opterons or Intel Xeons (‘amd64’) rather than ‘x86’, but 32-bit ‘x86’ executables are the default.) How these compilers identify⁷⁷ themselves is slightly confusing: Solaris Studio versions 12.3 and 12.4 report C++ 5.12 and 5.13, and Developer Studio 12.5 reports C++ 5.14. We will only consider 12.5 (May 2016): instructions for 12.3 can be found in versions of this manual for R 3.3.x.

There have been few reports on Solaris 11, with no known extra issues.

Solaris was last tested on Sparc machines in June 2017.

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. A version of the preferred GNU tar is (if installed) in /usr/sfw/bin. It may be necessary to avoid the tools in /usr/ucb: POSIX-compliant versions of some tools can be found in /usr/xpg4/bin and /usr/xpg6/bin.

A large selection of Open Source software can be installed from https://www.opencsw.org, by default installed under /opt/csw. Solaris 10 ships with bzlib version 1.0.6 (sufficient) but zlib version 1.2.3 (too old): OpenCSW has 1.2.8.

At least when compiling with Oracle compilers, Solaris uses far more stack space than other platforms. This makes it desirable to build PCRE with the option –disable-stack-for-recursion: the OpenCSW distribution was at the time of writing.

The Oracle compilers are unusual in not including /usr/local/include in the default include search path: R’s default CPPFLAGS=-I/usr/local/include remedies this. If you rely on OpenCSW software you may need CPPFLAGS=-I/opt/csw/include (or both).

You will need GNU libiconv and readline: the Solaris version of iconv is not sufficiently powerful.

The native make suffices to build R but a small number of packages require GNU make (some without good reason and without declaring it as ‘SystemRequirements’ in the DESCRIPTION file).

The support for the C99 long double type on Sparc hardware uses quad-precision arithmetic, and this is usually slow because it is done by software emulation. On such systems the configure option –disable-long-double can be used for faster but less accurate computations.

The Solaris time-zone conversion services seem to be unreliable pre-1916 in Europe (when daylight-savings time was first introduced): most often reporting in the non-existent DST variant. Using configure option –with-internal-tzcode is recommended, and required if you find time-zone abbreviations being given odd values (as has been seen on 64-bit builds without it).

When using the Oracle compilers do not specify -fast, as this disables IEEE arithmetic and make check will fail.

A little juggling of paths was needed to ensure GNU libiconv (in /usr/local) was used rather than the Solaris iconv:

CC="cc -xc99"
CFLAGS="-O -xlibmieee"
F77=f95
FFLAGS=-O
CXX=CC
CXXSTD="-library=stlport4"
CXXFLAGS=-O
FC=$F77
FCFLAGS=$FFLAGS
FCLIBS="-lfsu /opt/developerstudio12.5/lib/libfui.so.2"
R_LD_LIBRARY_PATH="/opt/developerstudio12.5/lib:/usr/local/lib:/opt/csw/lib"

The Oracle compilers do not by default conform to the C99 standard (appendix F 8.9) on the return values of functions such as log: use -xlibmieee to ensure this.

A peculiarity of the Fortran compiler is that when asked to link a shared object it does not link against the Fortran runtime libraries. In R this is only used for packages with F9x code, hence the FCLIBS definition (which sufficed for CRAN packages with 12.5).

Using -xlibmil in CFLAGS or -xlibmil in FFLAGS allows more system mathematical functions to be inlined.

On ‘x86’ you will get marginally higher performance via

CFLAGS="-xO5 -xlibmieee -xlibmil -nofstore -xtarget=native"
FFLAGS="-xO5 -libmil -nofstore -xtarget=native"
CXXFLAGS="-xO5 -xlibmil -nofstore -xtarget=native"
SAFE_FFLAGS="-O -libmil -fstore -xtarget=native"

but the use of -nofstore can be less numerically stable, and some packages have in the past failed to compile at optimization level 5.

The Oracle compilers provide several implementations of the C++98 standard which select both the set of headers and a C++ runtime library. These are selected by the -library flag, which as it is needed for both compiling and linking is best specified as part of the compiler. The examples above use ‘stlport4’, currently the most modern of the options: the default (but still needed to be specified as it is needed for linking) is ‘Cstd’: see http://www.oracle.com/technetwork/server-storage/solaris/cmp-stlport-libcstd-142559.html. Note though that most external Solaris C++ libraries will have been built with ‘Cstd’ and so an R package using such libraries also needs to be. Occasionally the option -library=stlport4,Crun has been needed.

The performance library sunperf is available for use with the Oracle compilers. If selected as a BLAS, it must also be selected as LAPACK via

./configure --with-blas='-library=sunperf' --with-lapack

This has often given test failures in the past, in several different places.⁷⁸

Parsing very complex R expressions needs a lot of stack space when the Oracle compilers are used: several packages require the stack increased to at least 20MB.

Some people have reported that the Solaris libintl needs to be avoided, for example by using –disable-nls or –with-included-gettext or using libintl from OpenCSW. (On the other hand, there have been many successful installs which automatically detected libintl from OpenCSW or selected the included gettext.)

It has been reported that some Solaris installations need

INTERNET_LIBS="-lsocket -lnsl"

on the configure command line or in file config.site; however, there have been many successful installs without this.

C.4.1 64-bit builds

On both ‘x86’ and ‘Sparc’ platforms the compilers default to 32-bit code.

For a 64-bit target add -m64 to the compiler macros and use something like LDFLAGS=-L/usr/local/lib/amd64 or LDFLAGS=-L/usr/local/lib/sparcv9 as appropriate (and other 64-bit library directories if used, e.g. -L/opt/csw/lib/arm64). It will also be necessary to point pkg-config at the 64-bit directories, e.g. by something like

PKG_CONFIG_PATH=/opt/csw/lib/64/pkgconfig:/usr/lib/64/pkgconfig

and to specify a 64-bit Java VM by e.g.

JAVA_CPPFLAGS="-I${JAVA_HOME}/../include -I${JAVA_HOME}/../include/solaris"
JAVA_LD_LIBRARY_PATH=${JAVA_HOME}/lib/amd64/server
JAVA_LIBS="-L${JAVA_HOME}/lib/amd64/server \
  -R${JAVA_HOME}/lib/amd64/server -ljvm"

C.4.2 Using gcc

If using gcc, 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 several reports of problems were due to using gcc compiled on one version of Solaris on a later version. Note that this can even apply to OS patches: some 2016 patches to Solaris 10 changed its C header files in way incompatible⁷⁹ with the modified versions included with OpenCSW’s binary distribution.

The notes here are for gcc set up to use the Solaris linker: it can also be set up to use GNU ld, but that has not been tested. The tests were for compilers from the OpenCSW repository: Solaris systems often come with much older compilers installed under /usr/sfw/bin. One of -m32 or -m64 will be the default and could be omitted, but it is not easy to find out which. (For OpenCSW it is -m32.)

Compilation for an ‘x86’ target with gcc 4.9.2 or gcc 5.2.0 needed

CC="gcc -m32"
CPPFLAGS="-I/opt/csw/include -I/usr/local/include"
F77="gfortran -m32"
CXX="g++ -m32"
FC=$F77
LDFLAGS="-L/opt/csw/lib -L/usr/local/lib"

For an ‘amd64’ target we used

CC="gcc -m64"
CPPFLAGS="-I/opt/csw/include -I/usr/local/include"
F77="gfortran -m64"
CXX="g++ -m64"
FC=$F77
LDFLAGS="-L/opt/csw/lib/amd64 -L/usr/local/lib/amd64"

Note that paths such as /opt/csw/lib, /usr/local/lib/amd64 and /opt/csw/lib/amd64 may need to be in the LD_LIBRARY_PATH during configuration.

C.5 AIX

We no longer support AIX prior to 4.2, and configure will throw an error on such systems.

Ei-ji Nakama was able to build under AIX 5.2 on ‘powerpc’ with GCC 4.0.3 in several configurations. 32-bit versions could be configured with –without-iconv as well as –enable-R-shlib. For 64-bit versions he used

OBJECT_MODE=64
CC="gcc -maix64"
CXX="g++ -maix64"
F77="gfortran -maix64"
FC="gfortran -maix64"

and was also able to build with the IBM xlc and Hitachi f90 compilers by

OBJECT_MODE=64
CC="xlc -q64"
CXX="g++ -maix64"
F77="f90 -cpu=pwr4 -hf77 -parallel=0 -i,L -O3 -64"
FC="f90 -cpu=pwr4 -hf77 -parallel=0 -i,L -O3 -64"
FLIBS="-L/opt/ofort90/lib -lhf90vecmath -lhf90math -lf90"

Some systems have f95 as an IBM compiler that does not by default accept FORTRAN 77. It needs the flag -qfixed=72, or to be invoked as xlf_r.

The AIX native iconv does not support encodings ‘latin1’ nor ‘“”’ and so cannot be used. (As far as we know GNU libiconv could be installed.)

Fan Long reported success on AIX 5.3 using

OBJECT_MODE=64
LIBICONV=/where/libiconv/installed
CC="xlc_r -q64" 
CFLAGS="-O -qstrict"
CXX="xlC_r -q64"
CXXFLAGS="-O -qstrict"
F77="xlf_r -q64"
AR="ar -X64"
CPPFLAGS="-I$LIBICONV/include -I/usr/lpp/X11/include/X11"
LDFLAGS="-L$LIBICONV/lib -L/usr/lib -L/usr/X11R6/lib"

On one AIX 6.x system it was necessary to use R_SHELL to set the default shell to be Bash rather than Zsh.

Kurt Hornik and Stefan Theussl at WU (Wirtschaftsuniversität Wien) successfully built R on a ‘powerpc’ (8-CPU Power6 system) running AIX 6.1, configuring with or without –enable-R-shlib (Ei-ji Nakama’s support is gratefully acknowledged).

It helps to describe the WU build environment first. A small part of the software needed to build R and/or install packages is available directly from the AIX Installation DVDs, e.g., Java 6 and X11. Additional open source software (OSS) is packaged for AIX in .rpm files and available from both IBM’s “AIX Toolbox for Linux Applications” (http://www-03.ibm.com/systems/power/software/aix/linux/) and http://www.oss4aix.org/download/. The latter website typically offers more recent versions of the available OSS. All tools needed and libraries downloaded from these repositories (e.g., GCC, Make, libreadline, etc.) are typically installed to /opt/freeware, hence corresponding executables are found in /opt/freeware/bin which thus needs to be in PATH for using these tools. As on other Unix systems one needs GNU libiconv as the AIX version of iconv is not sufficiently powerful. Additionally, for proper Unicode compatibility one should install the corresponding package from the ICU project (http://www.icu-project.org/download/), which offers pre-compiled binaries for various platforms which in case of AIX can be installed via unpacking the tarball to the root file system. For full LaTeX support one can install the TeX Live DVD distribution (https://www.tug.org/texlive/): it is recommended to update the distribution using the tlmgr update manager. For 64-bit R builds supporting Tcl/Tk this needs to installed from the sources as available pre-compiled binaries supply only 32-bit shared objects.

The recent WU testing was done using compilers from both the GNU Compiler Collection (version 4.2.4) which is available from one of the above OSS repositories, and the IBM C/C++ (XL C/C++ 10.01) as well as FORTRAN (XL Fortran 12.01) compilers (http://www14.software.ibm.com/webapp/download/byproduct.jsp#X).

To compile for a 64-bit ‘powerpc’ (Power6 CPU) target one can use

CC ="gcc -maix64 -pthread"
CXX="g++ -maix64 -pthread"
FC="gfortran -maix64 -pthread"
F77="gfortran -maix64 -pthread"
CFLAGS="-O2 -g -mcpu=power6"
FFLAGS="-O2 -g -mcpu=power6"
FCFLAGS="-O2 -g -mcpu=power6"

for the GCC and

CC=xlc
CXX=xlc++
FC=xlf
F77=xlf
CFLAGS="-qarch=auto -qcache=auto -qtune=auto -O3 -qstrict -ma"
FFLAGS="-qarch=auto -qcache=auto -qtune=auto -O3 -qstrict"
FCFLAGS="-qarch=auto -qcache=auto -qtune=auto -O3 -qstrict"
CXXFLAGS="-qarch=auto -qcache=auto -qtune=auto -O3 -qstrict"

for the IBM XL compilers. For the latter, it is important to note that the decision for generating 32-bit or 64-bit code is done by setting the OBJECT_MODE environment variable appropriately (recommended) or using an additional compiler flag (-q32 or -q64). By default the IBM XL compilers produce 32 bit code. Thus, to build R with 64-bit support one needs to either export OBJECT_MODE=64 in the environment or, alternatively, use the -q64 compiler options.

It is strongly recommended to install Bash and use it as the configure shell, e.g., via setting CONFIG_SHELL=/usr/bin/bash in the environment, and to use GNU Make (e.g., via (MAKE=/opt/freeware/bin/make).

Further installation instructions to set up a proper R development environment can be found in the “R on AIX” project on R-Forge (https://R-Forge.R-project.org/projects/aix/).

C.6 FreeBSD

There have been few recent reports on FreeBSD: there is a ‘port’ at https://www.freebsd.org/ports/math.html.

Use of ICU for collation and the configure option –with-internal-tzcode are desirable workarounds.

C.7 OpenBSD

Ingo Feinerer installed R version 3.2.2 on OpenBSD 5.8 arch ‘amd64’ (their name for ‘x86_64’). Details of the build (and patches applied) are at http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/math/R/. (Downgrading the zlib requirement to 1.2.3 is against the advice of the R developers.)

C.8 Cygwin

The 32-bit version has never worked well enough to pass R’s make check, and residual support from earlier experiments was removed in R 3.3.0.

The 64-bit version is completely unsupported.

C.9 New platforms

There are a number of sources of problems when installing R on a new hardware/OS platform. These include

Floating Point Arithmetic: R requires arithmetic compliant with IEC 60559, also known as IEEE 754. This mandates the use of plus and minus infinity and NaN (not a number) as well as specific details of rounding. Although almost all current FPUs can support this, selecting such support 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 required 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 Oracle compilers has caused R’s NaN to be set incorrectly, and gcc’s -ffast-math and clang’s -Ofast have given incorrect results.

Shared Objects: There seems to be very little agreement across platforms on what needs to be done to build shared objects. 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: 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.x and later on ‘ix86’ Linux defeat attempts by the LAPACK code to avoid computations entirely in extended-precision registers, so file src/modules/lapack/dlamc.f may need to be compiled without optimization. Set the configure variable SAFE_FFLAGS to the flags to be used for this file. If configure detects GNU FORTRAN it adds flag -ffloat-store to FFLAGS. (Other settings are needed when using icc on ‘ix86’ Linux, for example. Using -mpc64 is preferable on more recent GCC compilers.)

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 use the ‘R-devel’ mailing list to ask questions. We have had a fair amount of practice at porting R to new platforms …