In the course of building an R package that would depend on Rcpp, I investigated whether compiling these two packages with MS VC++ is feasible, having users (me included) that work principally from Visual Studio as an IDE. With a couple of adjustments, but not much, it appears possible at least with VS2013 (FYI https://github.com/jmp75/Rcpp/tree/build/msvc). I have compiled but not run extensively, but a working system looks "essentially doable". There appears to have been some questions in the past on this mailing list regarding compiling with the VC++ compiler in order to access libraries built with it, so I thought I may flag this. I am actually currently aiming to use an API deliberately in C, with opaque pointers, to avoid being bound to one C++ compiler for all R packages (including on Linux; for all I know the C++ name mangling scheme is compiler specific irrespective of OSes and whether this is Microsoft's or not). In other words, I may not seek to actively design/maintain an Rcpp that can be built with VC++ for my own work. Nevertheless, I'd be interested to hear whether this is of use to others, and if so get advice on how/what to contribute if not too onerous. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20150408/450403b6/attachment.html>
[Rcpp-devel] Rcpp built with the visual c++ compiler - possible uses
3 messages · Jean-Michel.Perraud at csiro.au, Dirk Eddelbuettel, Matt D.
On 8 April 2015 at 12:34, Jean-Michel.Perraud at csiro.au wrote:
| pointers, to avoid being bound to one C++ compiler for all R packages But you're not: We happily support g++, clang, the Intel compiler and (somewhat relunctantly) SunPro; see inst/include/Rcpp/platform/compiler.h I personally have no interest whatsoever in stretching our codebase for a compiler and system which has treated POSIX as an afterthought for decades. So I have my view on who has to change --- and with that I gratefully acknowledge that the change is happening in some places (eg MSFT help on RcppParallel support for Intel TBB in Windows). So if you were to write a blog post or tutorial about how to constrain a code base to use only C in the interface to make life with VC++ possible, I'd welcome a link to such a post. But this is the list for Rcpp, and we support the compilers supported by the R Project. That list does not include VC++. Dirk
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On 4/8/2015 14:34, Jean-Michel.Perraud at csiro.au wrote:
I am actually currently aiming to use an API deliberately in C, with opaque pointers, to avoid being bound to one C++ compiler for all R packages (including on Linux; for all I know the C++ name mangling scheme is compiler specific irrespective of OSes and whether this is Microsoft's or not).
Hi! Just a few small notes and pointers, perhaps some will be of use: (Some) level of application binary interface (ABI) compatibility with gcc is among the stated goals of Clang: http://stackoverflow.com/questions/3217513/are-llvm-gcc-and-clang-binary-compatible-with-gcc-particularly-mingw-gcc-on-w // The incompatibility related to `std::string` mentioned in the above is bound to go away in the upcoming GCC version; see "GCC 5 and the C++11 ABI": http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ If you're on POSIX, then Itanium C++ ABI is also the de-facto standard: https://mentorembedded.github.io/cxx-abi/abi.html More on that: "This mangling scheme is used in Gnu C++ version 3.x.x and later under several operating systems (Linux, BSD, Mac OS X IE32, Windows) and on several platforms. It is described in "Itanium C++ ABI". The same scheme is used by Intel compilers for Linux and Mac OS. Different variants are available for the Gnu compiler version 4.x.x [...]" Source: http://www.agner.org/optimize/calling_conventions.pdf In particular, Clang makes a point of maintaining mangling compatibility with GCC: http://clang.llvm.org/doxygen/ItaniumMangle_8cpp_source.html Now, all that being said, MSVC adheres to Microsoft ABI. "This complicates matters" (to put it mildly)... Unfortunately, this goes far beyond name mangling: "If name mangling was standardized, could I link code compiled with compilers from different compiler vendors? Short answer: Probably not." Why? https://isocpp.org/wiki/faq/compiler-dependencies#binary-compat So, a compiled (binary) library made by MSVC, exposing a function returning, say, an `std::string`, will almost surely fail to work with client code built with GCC. In fact, MSVC reserves the right to break binary compatibility with previous MSVC versions (on major versions updates). Incidentally, this is not unusual, and quite like GCC 5 breaking binary compatibility with GCC 4 (with `std::string` being exactly one of the differences). // Not sure what are the implications for binary shared libraries used from R at this point (if any). Thus, as you've mentioned, some interface constraining may be unavoidable. This is similar to the issues one encounters when exposing C++ libraries to C client code -- so some of the practices may be applicable, too: https://isocpp.org/wiki/faq/mixing-c-and-cpp Dirk has asked for a tutorial "a blog post or tutorial about how to constrain a code base to use only C in the interface". In this context, there are two resources that come to mind that perhaps may be of some help here -- possibly at least as useful starting points: "Hourglass Interfaces for C++ APIs" and "Beautiful Native Libraries". Stefanus DuToit's "Hourglass Interfaces for C++ APIs" CppCon 2014 presentation covers the set of best practices for dealing with the cross-platform ABI issues when exposing your libraries to the outside world: Video: https://www.youtube.com/watch?v=PVYdHDm0q6Y Slides: http://www.slideshare.net/StefanusDuToit/cpp-con-2014-hourglass-interfaces-for-c-apis Code: https://github.com/CppCon/CppCon2014/tree/master/Presentations/Hourglass Interfaces for C%2B%2B APIs Discussion: https://www.reddit.com/r/cpp/comments/2mx1mm/hourglass_interfaces_for_c_apis/ Armin Ronacher's "Beautiful Native Libraries" post (illustrated with examples of writing a C++ library to be used from Python -- but generally applicable to writing C++ libraries to be used from other languages, too) also offers some useful advice on the best practices and things to watch out for: http://lucumr.pocoo.org/2013/8/18/beautiful-native-libraries/ Discussion: https://news.ycombinator.com/item?id=6235671 Other than that, libabigail -- https://sourceware.org/libabigail/ -- may also come in handy: http://developerblog.redhat.com/2014/10/23/comparing-abis-for-compatibility-with-libabigail-part-1/ http://developerblog.redhat.com/2014/10/28/comparing-abis-for-compatibility-libabigail-part-2/ More forward-looking, but also offering a brief overview of the existing issues and more pointers/references, is a proposal for the C++ ABI standardization: http://isocpp.org/blog/2014/05/n4028 (PDF) https://isocpp.org/files/papers/n4028.pdf HTH! Best, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20150408/ce054502/attachment.html>