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 <e...@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 | e...@debian.org | http://dirk.eddelbuettel.com
-----------------------------------------------
Michael Braun
Associate Professor of Marketing
MIT Sloan School of Management
617-253-3436
bra...@mit.edu
http://braunm.scripts.mit.edu/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
