Rcpp: Possible g++ 6.3.0 issue

Created on 22 Mar 2017  Â·  8Comments  Â·  Source: RcppCore/Rcpp

Unable to compile Rcpp modules with g++ version 6.3.0 installed through homebrew.

Things work as advertised with clang or gcc 5.x.

Steps to reproduce

  • Install gcc 6.3.0
brew install gcc
  • Modify Makevars to use gcc
echo "CC=gcc-6" >> ~/.R/Makevars 
echo "CXX=g++-6" >> ~/.R/Makevars
  • Create an example Rcpp module
> sessionInfo()
R version 3.3.3 (2017-03-06)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: macOS Sierra 10.12.3

locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

> Rcpp::Rcpp.package.skeleton("testmod", module = T)
# ...
  • Attempt to install module
> R CMD INSTALL --preclean --no-multiarch --with-keep.source testmod

Output produced:

* installing to library ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library’
* installing *source* package ‘testmod’ ...
** libs
g++-6 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG  -I/usr/local/include -I/usr/local/include/freetype2 -I/opt/X11/include -I"/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include"   -fPIC  -Wall -mtune=core2 -g -O2  -c Num.cpp -o Num.o
g++-6 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG  -I/usr/local/include -I/usr/local/include/freetype2 -I/opt/X11/include -I"/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include"   -fPIC  -Wall -mtune=core2 -g -O2  -c RcppExports.cpp -o RcppExports.o
g++-6 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG  -I/usr/local/include -I/usr/local/include/freetype2 -I/opt/X11/include -I"/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include"   -fPIC  -Wall -mtune=core2 -g -O2  -c rcpp_hello_world.cpp -o rcpp_hello_world.o
g++-6 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG  -I/usr/local/include -I/usr/local/include/freetype2 -I/opt/X11/include -I"/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include"   -fPIC  -Wall -mtune=core2 -g -O2  -c rcpp_module.cpp -o rcpp_module.o
g++-6 -I/Library/Frameworks/R.framework/Resources/include -DNDEBUG  -I/usr/local/include -I/usr/local/include/freetype2 -I/opt/X11/include -I"/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcpp/include"   -fPIC  -Wall -mtune=core2 -g -O2  -c stdVector.cpp -o stdVector.o
g++-6 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o testmod.so Num.o RcppExports.o rcpp_hello_world.o rcpp_module.o stdVector.o -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
installing to /Library/Frameworks/R.framework/Versions/3.3/Resources/library/testmod/libs
** R
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
sh: line 1: 84595 Abort trap: 6           '/Library/Frameworks/R.framework/Resources/bin/R' --no-save --slave 2>&1 < '/var/folders/rk/xv9h1cj162vctr73yq2g18dw0000gn/T//RtmpsZ8M1M/file14a3d529b6df6'
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid
ERROR: loading failed
* removing ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/testmod’
* restoring previous ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/testmod’

EDIT: included full output

Most helpful comment

My guess -- Homebrew's gcc comes with its own standard library implementation (libstdc++), while R packages by default use the system libc++ standard library implementation. When you mix Homebrew gcc with CRAN R, you end up mixing standard libraries and things blow up.

All 8 comments

(Please edit the report to include the text from the quoted file. What you do right now is inefficient and wastes the time of every reader.)

As a first guess, it looks like incompatible object code. Did you recompile Rcpp and R with the same compiler? You may have too...

Note that CRAN pretty aggressively tests on new (as in: unreleased) compilers too and we haven't heard from them so my instinct would be to suspect a setup error on your end ...

Okay, I included the full output.

I am using the CRAN binary for both R and Rcpp.

What you are suggesting is those were compiled with clang on CRAN side, right?

I am no expert on brew and OS X besides hearing every now and then how things break.

You need to talk to the people who built those binaries for you. As I understand it they use a different compiler. If you then randomly mix and match and things break, you get to keep the pieces.

You always need a consistent tool chain.

I think you have to brew install r if you want to use the homebrew compilers on Mac.
See this: http://stackoverflow.com/a/26457411

Fair enough. Thanks for clarifying this.

Lastly, our current r-base Docker image for R uses this very compiler without any issues:

$ docker run --rm -ti r-base /bin/bash
root@46b13454ca83:/# g++ --version
g++ (Debian 6.3.0-8) 6.3.0 20170221
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@46b13454ca83:/# R --version
R version 3.3.3 (2017-03-06) -- "Another Canoe"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
http://www.gnu.org/licenses/.

root@46b13454ca83:/# 

My guess -- Homebrew's gcc comes with its own standard library implementation (libstdc++), while R packages by default use the system libc++ standard library implementation. When you mix Homebrew gcc with CRAN R, you end up mixing standard libraries and things blow up.

@kevinushey Sounds very reasonable. I will have to do some digging to figure out if that's the reason.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jgellar picture jgellar  Â·  8Comments

epipping picture epipping  Â·  7Comments

PeteHaitch picture PeteHaitch  Â·  6Comments

progtw picture progtw  Â·  8Comments

krlmlr picture krlmlr  Â·  9Comments