[Rd] Experimental CXX_STD problem in R 3.4

[Martyn Plummer]

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