C++ support across different platforms is now very heterogeneous. The standard is evolving rapidly but there are also platforms in current use that do not support the recent iterations of the standard. Our goal for R 3.4.0 is to give as much flexibility as possible. The default compiler is whatever you get "out of the box" without setting the "-std=" flag. This means different things on different platforms. If you need a specific standard there are various ways to request one, as described in the R-exts manual. On unix-alikes, the capabilities of the compiler are tested at configure time and appropriate flags chosen to support each standard. On Windows, the capabilities are hard-coded and correspond to the current version of Rtools, i.e. only C++98 and C++11 are currently supported. C++17 support is experimental and was added very recently. Clang 4.0.0, which was released last week, passes the configuration tests for C++17, and so does gcc 7.0.1, the pre-release version of gcc 7.1.0 which is due out later this year. The tests for C++17 features are, however, incomplete. I have just added some code to ensure that the compilation fails with an informative error message if a specific C++ standard is requested but the corresponding compiler has not been defined. Please test this. Martyn ________________________________________ From: R-devel <r-devel-bounces at r-project.org> on behalf of Dirk Eddelbuettel <edd at debian.org> Sent: 18 March 2017 15:55 To: Jeroen Ooms Cc: r-devel Subject: Re: [Rd] Experimental CXX_STD problem in R 3.4 On 18 March 2017 at 14:21, Jeroen Ooms wrote: | R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11 | / CXX14 / CXX17. R 3.1.0 introduced CXX11 support. R 3.4.0 will have CXX14 support. So I would only refer to the CXX17 part as experimental. | However on most platforms, the R configuration seems to leave the | CXX1Y and CXX1Z fields blank in "${R_HOME}/etc/Makeconf" (rather than | falling back on default CXX). Therefore specifying e.g CXX_STD= CXX14 | will fail build with cryptic errors (due to compiling with CXX="") That depends of course on the compiler found on the system. On my box (with g++ being g++-6.2 which _defaults_ to C++14) all is well up to CXX1Y. But I also have CXX1Z empty. | I don't think this is intended? Some examples from r-devel on Windows: | | CXX11: https://win-builder.r-project.org/R8gg703OQSq5/ | CXX98: https://win-builder.r-project.org/mpVfXxk79FaN/ | CXX14: https://win-builder.r-project.org/L3BSMgAk4cQ7/ | CXX17: https://win-builder.r-project.org/3ETZXrgkg77I/ You can't expect CXX14 and CXX17 to work with the only available compiler there, g++-4.9.3. | Similar problems appear on Linux. I think the problem is that Makeconf | contains e.g: | | CXX1Z | CXX1ZFLAGS | CXX1ZPICFLAGS | CXX1ZSTD | | When CXX_STD contains any other unsupported value (e.g. CXX24) R | simply falls back on the default CXX configuration. The same should | probably happen for e.g. CXX17 when CXX1Z is unset in Makeconf? Probably. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel ----------------------------------------------------------------------- This message and its attachments are strictly confidenti...{{dropped:8}}
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer <plummerm at iarc.fr> wrote:> I have just added some code to ensure that the compilation fails with an informative error message if a specific C++ standard is requested but the corresponding compiler has not been defined. Please test this.Are you sure we shouldn't just fall back on a previous standard instead of failing? For example if the package author has specified a preference for CXX14 but the compiler only has CXX11, the package might still build with -std=c++11 (given that C++14 is only a small extension on the C++11 standard). The current behavior (in R 3.3) for packages with "CXX_STD=CXX11" is to fall back on CXX when the compiler does not have CXX1X. Will R-3.4 start failing these packages? This would affect many users on CentOS 6 (gcc 4.4.7).
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer <plummerm at iarc.fr> wrote:> I have just added some code to ensure that the compilation fails with an informative error message if a specific C++ standard is requested but the corresponding compiler has not been defined. Please test this.I can confirm that (at least on Windows) we get a proper error message for CXX14 and CXX17, eg: * installing *source* package 'testcxx' ... ** libs Error in .shlib_internal(args) : C++14 standard requested but CXX1Y is not defined * removing 'C:/Program Files/R/R-devel/library/testcxx' CXX98 still does not work though. It seems SHLIB_CXX98LD is undefined on Windows? * installing *source* package 'testcxx' ... ** libs c:/Rtools/mingw_64/bin/g++ -std=gnu++98 -I"C:/PROGRA~1/R/R-devel/include" -DNDEBUG -I"d:/Compiler/gcc-4.9.3/local330/include" -O2 -Wall -mtune=core2 -c test.cpp -o test.o -shared -s -static-libgcc -o testcxx.dll tmp.def test.o -Ld:/Compiler/gcc-4.9.3/local330/lib/x64 -Ld:/Compiler/gcc-4.9.3/local330/lib -LC:/PROGRA~1/R/R-devel/bin/x64 -lR -shared: not found no DLL was created ERROR: compilation failed for package 'testcxx'
On Mon, 2017-03-20 at 16:38 +0100, Jeroen Ooms wrote:> On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer <plummerm at iarc.fr> > wrote: > > I have just added some code to ensure that the compilation fails > > with an informative error message if a specific C++ standard is > > requested but the corresponding compiler has not been defined. > > Please test this. > > Are you sure we shouldn't just fall back on a previous standard > instead of failing? For example if the package author has specified a > preference for CXX14 but the compiler only has CXX11, the package > might still build with -std=c++11 (given that C++14 is only a small > extension on the C++11 standard). > > The current behavior (in R 3.3) for packages with "CXX_STD=CXX11" is > to fall back on CXX when the compiler does not have CXX1X.I don't think that is true.> Will R-3.4 > start failing these packages? This would affect many users on CentOS 6 > (gcc 4.4.7).The major issue with long-term support platforms like CentOS is that the compiler is rather old. According to the GCC web site, 4.4.7 has partial support for C++11 via the -std=c++0x flag ( https://gcc.gnu.org /projects/cxx-status.html#cxx11 ). The problem is that the tests for C++11 compliance used by R's configure script have become much more stringent. If g++ 4.4.7 passed before, it is unlikely to pass now. This is an issue that I discussed here. https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17189 This creates a regression on older platforms. Some packages that used only a few C++11 features used to compile correctly but now don't because the compiler is no longer recognized as conforming to the C++11 standard (and to be fair it never did but the previous tests were weaker). What I suggest is that on these platforms you do a post-install patch of etc/Makeconf and set the variables for the C++11 compiler manually (CXX11, CXX11FLAGS, CXX11PICFLAGS, CXX11STD, SHLIB_CXX11LD, SHLIB_CXX11LDFLAGS). Martyn