I think this bit:
The \texttt{clang} and \texttt{clang++} compilers from the LLVM project can
also be used as they are inter-operable with \texttt{gcc} et al. The
\texttt{clang++} compiler is interesting as it emits much more
comprehensible error messages than \texttt{g++} (though \texttt{g++} 4.8
and 4.9
have caught up).
needs to be amended. The standard library implementation used with gcc
(libstdc++) is not ABI compatible with the one used with clang (libc++).
This has been a common pain point for users running Snow Leopard who
updated their operating system to Mavericks, and also installed Mavericks
R, without re-installing any previously installed packages -- having a
clang-compiled package with C++ code try to link to an older gcc-compiled
package with C++ code caused many headaches for users, either with weird
segfaults or errors on loading packages or (if lucky) errors at link time.
In addition:
OS X used to be a little more conservative with compiler versions as Apple
stuck with gcc-4.2. Following the 'Mavericks' release, it is the opposite
as
only llvm is provide in Xcode---while the R build provided by CRAN still
has
hardwired settings for the gcc/g++ combination.
Until that is resolved, users either need to create softlinks (say, in,
\code{/usr/local/bin}) or override the \code{CC} and \code{CXX} variables
via a
file \code{~/.R/Makevars} or its system-equivalent in R's \code{etc/}
directory. Also see \faq{q:OSXArma} below. In general, consult the
\code{r-sig-mac} mailing list for further details.
There are now two separate CRAN binaries, one compiled for Snow Leopard
and above (using gcc-4.2.1), and one compiled for Mavericks (using the
latest clang release distributed with Mavericks). Fortunately, since R
doesn't include any C++ code, one can use Snow Leopard R with
clang-compiled packages containing C++ code with no problems. However,
packages containing C++ code should be compiled with the same compiler
suite. This is a bit of a pain point for users of Snow Leopard R who might
be using clang -- the binaries distributed by CRAN are compiled with
gcc-4.2 and libstdc++ (by default) and those won't be compatible with
packages compiled from source with clang++ and libc++.
Professor Ripley compiled a set of recommendations in a post on R-SIG-Mac
that we could link to:
https://stat.ethz.ch/pipermail/r-sig-mac/2014-April/010835.html
We might also link to the BioConductor guidelines for Mavericks + C++11
development:
http://www.bioconductor.org/developers/how-to/mavericks-howto/; it's a
nice overview of the state of the world there.
The general prescription, I think:
1. If you want to mix and match CRAN binaries with packages installed from
source, make sure your compiler suite matches that of the CRAN R you've
installed. Otherwise, the safer route is to compile all packages from
source.
2. If you're running OS X Mavericks (or greater), and want to compile
packages from source (ostensibly using clang), use the Mavericks CRAN R
binary, otherwise you will run into frustrating ABI compatibility issues
(as Snow Leopard R will grab CRAN package binaries compiled with gcc 4.2;
again incompatible with those compiled with clang)*.
I can try to amend the vignette to this effect later and submit a PR. If
anyone else on the list thinks I missed something here, let me know too.
Cheers,
Kevin
*I suppose someone running Mavericks with a Snow Leopard R could set the
'pkgType' option (see ?install.packages) to grab Mavericks binaries of
packages, but I doubt this is recommended.
PS: A useful utility one could write would check what C++ standard library
implementation each installed package links to. Maybe I'll write that...
On Sun, Aug 3, 2014 at 9:17 AM, Dirk Eddelbuettel <edd at debian.org> wrote: