Quantcast

Experimental CXX_STD problem in R 3.4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Experimental CXX_STD problem in R 3.4

Jeroen Ooms
R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11
/ CXX14 / CXX17.

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="")

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/

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?

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental CXX_STD problem in R 3.4

Dirk Eddelbuettel

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 | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental CXX_STD problem in R 3.4

Martyn Plummer-3
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 <[hidden email]> on behalf of Dirk Eddelbuettel <[hidden email]>
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 | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental CXX_STD problem in R 3.4

Jeroen Ooms
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer <[hidden email]> 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).

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental CXX_STD problem in R 3.4

Jeroen Ooms
In reply to this post by Martyn Plummer-3
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer <[hidden email]> 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'

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental CXX_STD problem in R 3.4

Martyn Plummer-3
In reply to this post by Jeroen Ooms
On Mon, 2017-03-20 at 16:38 +0100, Jeroen Ooms wrote:

> On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer <[hidden email]>
> 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
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Loading...