[Rcpp-devel] Rcpp-FAQ vignette and OS X entries: Small update

[Kevin Ushey]

As promised:

otool <- Sys.which("otool")
if (otool == "") {
  stop("This utility requires 'otool' to run")
}

allPackages <- list.files(.libPaths(), full.names = TRUE)
stdLibsUsed <- lapply(allPackages, function(path) {
  pkgName <- basename(path)
  libPath <- file.path(path, "libs", paste0(pkgName, ".so"))
  if (!file.exists(libPath)) {
    return(character())
  }
  otoolOutput <- system2("otool", args = c("-L", libPath), stdout = TRUE)
  c(
    "libc++"[any(grepl("libc++", otoolOutput, fixed = TRUE))],
    "libstdc++"[any(grepl("libstdc++", otoolOutput, fixed = TRUE))]
  )
})

pkgsWithLibStdCpp <- allPackages[sapply(stdLibsUsed, function(x) {
  "libstdc++" %in% x
})]

pkgsWithLibCpp <- allPackages[sapply(stdLibsUsed, function(x) {
  "libc++" %in% x
})]

list(
  "libstdc++" = pkgsWithLibStdCpp,
  "libc++" = pkgsWithLibCpp
)


I'm not sure where this could live, but basically, Mavericks users who see
any packages linking to `libstdc++` would probably want to reinstall those
packages. There may be some packages that need to explicitly link to
libstdc++ even on a Mavericks system for other reasons, though...

That said, most of the initial migration headaches seem to be over so this
probably would have been more useful half a year ago ;)

Cheers,
Kevin


On Sun, Aug 3, 2014 at 1:10 PM, Kevin Ushey <kevinushey at gmail.com> wrote:

> 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:
>
>>
>> I noticed a post cross-referenced on R Bloggers about Rcpp(Armadillo), OS
>> X
>> and the need for an additional Fortran packages from Simon's site -- so I
>> took this as opportunity to update the OS X answers in the Rcpp FAQ
>> vignette.
>>
>> As I don't use OS X, I'd appreciate a second set of eyes by anyone with a
>> moment to spare and some mad OS X "skillz".
>>
>> Current Rnw file
>>   https://github.com/RcppCore/Rcpp/blob/master/vignettes/Rcpp-FAQ.Rnw
>>
>> Link to the committed changes
>>
>> https://github.com/RcppCore/Rcpp/commit/e892622ce1c741f47b2e43b1d44ece32d44ee239
>>
>> Corrections and improvements to other parts are of course welcome as well
>> :)
>>
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140803/3989ab4e/attachment-0001.html>