[Rcpp-devel] Using Rcpp with C++11 and clang

[Michael Braun]

Dirk:

Thanks for the kind words, although I'm not sure that 2 packages constitutes a flood.

The only reason I was using c++11 was to access some mathematical functions in TR1.  I can work around that, so I do not have to send any C++11 code to CRAN.

But still, playing around with some more, the issue appears to be with libc++.  When -std=c++11, clang links to libc++ by default, while gcc and intel both link to libstdc++.  If I set -stdlib=libstdc++ in clang, it all works. For some reason, it appears that libstdc++ has tr1/unordered_map, but libc++ does not.  

The problem is that combining C++11 and libstdc++ is giving me some problems with other libraries, and not all of my code goes into a CRAN package.  So it would be great if Rcpp were libc++ - compatible, even if CRAN is not.  For example, would it be possible to undefine the HAS_TR1_UNORDERED_MAP macro for a Mac + clang + libc++ combination?

Michael


On Aug 28, 2012, at 3:09 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

> 
> Hi Michael,
> 
> Congrats on your recent flooding of CRAN with packages :)
> 
> On 28 August 2012 at 18:46, Michael Braun wrote:
> | Is it possible that there is some kind of incompatibility among clang, libc++ and Rcpp? Consider this super-simple example (filename is  tr1.cpp):
> | 
> | #include <Rcpp.h>
> | RcppExport SEXP testtr1() {
> |   return(Rcpp::wrap(0));
> | }
> | 
> | If I compile it as a dynamic library with clang, I get:
> | 
> | clang -O3  -m64 -msse4.2 -std=c++11 -stdlib=libc++ -I/Library/Frameworks/R.framework/Headers -I/Library/Frameworks/R.framework/Resources/library/Rcpp/include   -c tr1.cpp -o tr1.o 
> | 
> | In file included from tr1.cpp:1:
> | In file included from /Library/Frameworks/R.framework/Resources/library/Rcpp/include/Rcpp.h:27:
> | /Library/Frameworks/R.framework/Resources/library/Rcpp/include/RcppCommon.h:143:10: fatal error: 'tr1/unordered_map' file not found
> | #include <tr1/unordered_map>
> |          ^
> | 1 error generated.
> | 
> | This works fine with the Intel compiler, as well as with gcc version 4.6.1.
> | 
> | Looking at RcppCommon.h, I see that there are a number of checks, including the definition of HAS_TR!_UNORDERED_MAP.   Is it possible that this code defines this macro for clang, when it shouldn't?
> | 
> | The version of clang I am using is:
> | 
> | Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)
> | Target: x86_64-apple-darwin12.1.0
> | Thread model: posix
> | 
> | Rcpp is version 0.9.13.  My OS is Mac OSX 10.8.1, and I have installed XCode 4.4.1, with the latest command line tools.
> | 
> | I see that this issue has been brought up in the past, but I have not been able to find a resolution.  Since clang appears to be Apple's preferred compiler in XCode, I thought you might like to know about this, and perhaps let me know if I have made some kind of mistake.
> 
> There are two (to three) distinct issues here:
> 
> i)  clang -- and I do from time to time test with clang which works just fine
>    "as is", ie on my Linux box I simply say this in ~/.R/Makevars
> 
>    CXX=clang++
>    CC=clang
> 
>    and R builds just fine, as does Rcpp.  As I follow whatever Ubuntu gives
>    me, I am still at clang 3.0, but I expect no changes from clang 3.1
> 
> ii) c++11 -- and Romain and I were enthusiastic about it early as brings so
>    many new features.  Only to be told by CRAN (and one vocal person in
>    particular) that this is non-standard, non-portable, non-kosher, ...
>    so we relented.  I still have this in ~/.R/Makevars
> 
>    #CXXFLAGS=            -g  -O3 -Wall -pipe -pedantic -Wno-variadic-macros 
>    #CXXFLAGS=            -g0 -O3 -Wall -pipe -pedantic -Wno-variadic-macros 
>    #CXXFLAGS= -std=c++0x -g  -O3 -Wall -pipe -pedantic -Wno-variadic-macros 
> 
>    so all it takes is to enable -std=c++0x.  AFAIK clang++ uses that switch too.
> 
>    But do understand that such code cannot go to CRAN until the
>    powers-that-be decide otherwise.
> 
> Now, there could possibly be an intersection of issues with i) AND ii) but I
> don't think so. Similarly, there could as always be something special going
> on with OS X, in which case someone else will need to help you with the finer
> aspects of that environment.
> 
> Hth,  Dirk
> 
> 
> -- 
> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com  

-----------------------------------------------
Michael Braun 
Associate Professor of Marketing
MIT Sloan School of Management
617-253-3436
braunm at mit.edu
http://braunm.scripts.mit.edu/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1583 bytes
Desc: not available
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20120828/1c755674/attachment.bin>