Skip to content

Ubuntu 16.10 Yakkety Yak uses GCC 6 but -std=c++98 is missing

12 messages · Kirill Müller, Dirk Eddelbuettel, George N. White III

Original
Kirill Müller
# 
After upgrading to Ubuntu 16.10, which brings GCC 6, I've noticed that 
packages are compiled in C++14 mode by default. Here's what a g++ 
command for compiling one of Rcpp's modules look like on my system:

g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/     -fpic  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g  -c barrier.cpp -o barrier.o

According to GCC news [1], the default is now C++14 if no -std is given. 
R-admin suggests adapting the configuration for GCC 6 [2].

I'm using r-base-core in version 3.3.2-1xenial0 from the Ubuntu repo 
[3]. Please advise.


Best regards

Kirill


[1] https://gcc.gnu.org/gcc-6/changes.html
[2] 
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#C_002b_002b-Support
[3] http://stat.ethz.ch/CRAN/bin/linux/ubuntu
Dirk Eddelbuettel
#
On 11 November 2016 at 23:48, Kirill M?ller wrote:
| After upgrading to Ubuntu 16.10, which brings GCC 6, I've noticed that 
| packages are compiled in C++14 mode by default. Here's what a g++ 
| command for compiling one of Rcpp's modules look like on my system:
| 
| g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/     -fpic  -g -O2 
| -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
| -D_FORTIFY_SOURCE=2 -g  -c barrier.cpp -o barrier.o
| 
| According to GCC news [1], the default is now C++14 if no -std is given. 
| R-admin suggests adapting the configuration for GCC 6 [2].
| 
| I'm using r-base-core in version 3.3.2-1xenial0 from the Ubuntu repo 
| [3]. Please advise.

Hm. We had g++-6.* (which does indeed default to C++14) in Debian unstable
for a while now, without problems.

This issue _may_ be fixable by rebuilding r-base-core, but then it would have
been needed for Debian too. Not sure.

This may be an Ubuntu-lagging-Debian issue because we may be rebuilding more
consistently in Debian whereas Ubuntu thinks that R is built with gcc-5 (as
it was) but is now used with gcc-6. Ooops.

You _could_ try idea this by editing /etc/R/Makeconf and inserting the
missing -std=c++-98 for the default CXX builds.

I am still on 16.04 with my machines as I had too much other stuff going on.
Please try a test or two at your end and report back. We should be able to
get this squared.

Dirk
Dirk Eddelbuettel
#
On 11 November 2016 at 23:48, Kirill M?ller wrote:
| After upgrading to Ubuntu 16.10, which brings GCC 6, I've noticed that 
| packages are compiled in C++14 mode by default. Here's what a g++ 
| command for compiling one of Rcpp's modules look like on my system:
| 
| g++ -I/usr/share/R/include -DNDEBUG -I../inst/include/     -fpic  -g -O2 
| -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
| -D_FORTIFY_SOURCE=2 -g  -c barrier.cpp -o barrier.o
| 
| According to GCC news [1], the default is now C++14 if no -std is given. 
| R-admin suggests adapting the configuration for GCC 6 [2].
| 
| I'm using r-base-core in version 3.3.2-1xenial0 from the Ubuntu repo 
| [3]. Please advise.

Hm. We had g++-6.* (which does indeed default to C++14) in Debian unstable
for a while now, without problems.

This issue _may_ be fixable by rebuilding r-base-core, but then it would have
been needed for Debian too. Not sure.

This may be an Ubuntu-lagging-Debian issue because we may be rebuilding more
consistently in Debian whereas Ubuntu thinks that R is built with gcc-5 (as
it was) but is now used with gcc-6. Ooops.

You _could_ try idea this by editing /etc/R/Makeconf and inserting the
missing -std=c++-98 for the default CXX builds.

I am still on 16.04 with my machines as I had too much other stuff going on.
Please try a test or two at your end and report back. We should be able to
get this squared.

Dirk
Kirill Müller
# 
Thanks. I have now CXX = g++ -std=c++98 in my /etc/R/Makeconf, it's 
picked up properly. I can only assume that the last -std= option wins if 
more than one are given on the same command line [1].


-Kirill


[1] http://stackoverflow.com/q/40563269/946850
On 12.11.2016 03:01, Dirk Eddelbuettel wrote:
Dirk Eddelbuettel
#
On 12 November 2016 at 14:23, Kirill M?ller wrote:
| Thanks. I have now CXX = g++ -std=c++98 in my /etc/R/Makeconf, it's 
| picked up properly. I can only assume that the last -std= option wins if 
| more than one are given on the same command line [1].

Good to know it works.

I am still a little puzzled why it was needed when it doesn't seem to be
needed on the Debian side.

Dirk
Dirk Eddelbuettel
#
On 12 November 2016 at 07:59, Dirk Eddelbuettel wrote:
|
| On 12 November 2016 at 14:23, Kirill M?ller wrote:
| | Thanks. I have now CXX = g++ -std=c++98 in my /etc/R/Makeconf, it's 
| | picked up properly. I can only assume that the last -std= option wins if 
| | more than one are given on the same command line [1].
| 
| Good to know it works.
| 
| I am still a little puzzled why it was needed when it doesn't seem to be
| needed on the Debian side.

I just upgraded an old (unused, underpowered) box to 16.10 as a first
test. No issues so far, and basic cppFunction("...") tests with Rcpp work.

Could you get us a minimal reproducible example of what broke without the
explicit -std=c++98 ?

Dirk
Kirill Müller
#
On 12.11.2016 18:38, Dirk Eddelbuettel wrote:
When I posted, there was only "xenial", not "yakkety", on CRAN. This has 
changed now (thanks a lot!). When I try to upgrade, I'm presented with 
the following diff of /etc/R/Makeconf (excerpt), which looks *very* 
strange to me.

-# configure  '--prefix=/usr' '--with-cairo' '--with-jpeglib' 
'--with-readline' '--with-tcltk' '--with-system-bzlib' 
'--with-system-pcre' '--with-system-zlib' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--datadir=/usr/share/R/share' 
'--includedir=/usr/share/R/include' '--with-blas' '--with-lapack' 
'--enable-R-profiling' '--enable-R-shlib' '--enable-memory-profiling' 
'--without-recommended-packages' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'R_PRINTCMD=/usr/bin/lpr' 
'R_PAPERSIZE=letter' 'R_BROWSER=xdg-open' 'LIBnn=lib' 
'JAVA_HOME=/usr/lib/jvm/default-java' 'CC=gcc -std=gnu99' 'CFLAGS=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 
'CPPFLAGS=' 'F77=gfortran' 'FFLAGS=-g -O2 -fstack-protector-strong' 
'CXX=g++' 'CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g' 
'FC=gfortran' 'FCFLAGS=-g -O2 -fstack-protector-strong'
+# configure  '--prefix=/usr' '--with-cairo' '--with-jpeglib' 
'--with-readline' '--with-tcltk' '--with-system-bzlib' 
'--with-system-pcre' '--with-system-zlib' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--datadir=/usr/share/R/share' 
'--includedir=/usr/share/R/include' '--with-blas' '--with-lapack' 
'--enable-R-profiling' '--enable-R-shlib' '--enable-memory-profiling' 
'--without-recommended-packages' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'R_PRINTCMD=/usr/bin/lpr' 
'R_PAPERSIZE=letter' 'R_BROWSER=xdg-open' 'LIBnn=lib' 
'JAVA_HOME=/usr/lib/jvm/default-java' 'CC=gcc -std=gnu99' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/r-base-qk3a9o/r-base-3.3.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro' 
'CPPFLAGS=' 'F77=gfortran' 'FFLAGS=-g -O2 
-fdebug-prefix-map=/build/r-base-qk3a9o/r-base-3.3.2=. 
-fstack-protector-strong' 'CXX=g++' 'CXXFLAGS=-g -O2 
-fdebug-prefix-map=/build/r-base-qk3a9o/r-base-3.3.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g' 'FC=gfortran' 'FCFLAGS=-g -O2 
-fdebug-prefix-map=/build/r-base-qk3a9o/r-base-3.3.2=. 
-fstack-protector-strong'


-CFLAGS = -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g $(LTO)
+CFLAGS = -g -O2 -fdebug-prefix-map=/build/r-base-qk3a9o/r-base-3.3.2=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -g $(LTO)

Also, no "-std=c++98" in the maintainer's version.

I noticed this because plogr logging crashed in dplyr (compiled with gcc 
6) right after upgrading to yakkety; I still had a gcc-5 built version 
of Rcpp installed. As soon as I added -std, everything worked as before. 
No minimal example, sorry. Don't we need "-std=c++98" in Makevars 
anyway, even if it's just to avoid users using C++11 constructs and then 
wondering why their packages fail on CRAN?


-Kirill


-Kirill
Dirk Eddelbuettel
#
On 12 November 2016 at 22:54, Kirill M?ller wrote:
[... lots of stuff deleted ...]

| I noticed this because plogr logging crashed in dplyr (compiled with gcc 
| 6) right after upgrading to yakkety; I still had a gcc-5 built version 
| of Rcpp installed. As soon as I added -std, everything worked as before. 
| No minimal example, sorry. Don't we need "-std=c++98" in Makevars 
| anyway, even if it's just to avoid users using C++11 constructs and then 
| wondering why their packages fail on CRAN?

There is still no minimally preproducible example here; just a (pardon me
here) rambling description of a hasty system upgrade.

It is _somewhat common_ to have to recompile C++ shared objects when compiler
major versions change.

So I am unsure if we have actually demonstrated a bug here.

Dirk
Kirill Müller
#
On 13.11.2016 00:00, Dirk Eddelbuettel wrote:
Don't we need "-std=c++98" for GCC 6 in Makevars anyway, even if it's 
just to save users from using C++11 constructs and then wondering why 
their packages fail on CRAN/winbuilder? In my case it also saves me from 
recompiling "all of CRAN" (at least for now); that's a nice side effect, 
but the first part also looks important to me.


-Kirill
Dirk Eddelbuettel
#
On 13 November 2016 at 00:13, Kirill M?ller wrote:
| On 13.11.2016 00:00, Dirk Eddelbuettel wrote:
| > On 12 November 2016 at 22:54, Kirill M?ller wrote:
| >
| > [... lots of stuff deleted ...]
| >
| > | I noticed this because plogr logging crashed in dplyr (compiled with gcc
| > | 6) right after upgrading to yakkety; I still had a gcc-5 built version
| > | of Rcpp installed. As soon as I added -std, everything worked as before.
| > | No minimal example, sorry. Don't we need "-std=c++98" in Makevars
| > | anyway, even if it's just to avoid users using C++11 constructs and then
| > | wondering why their packages fail on CRAN?
| >
| > There is still no minimally preproducible example here; just a (pardon me
| > here) rambling description of a hasty system upgrade.
| >
| > It is _somewhat common_ to have to recompile C++ shared objects when compiler
| > major versions change.
| >
| > So I am unsure if we have actually demonstrated a bug here.
| Don't we need "-std=c++98" for GCC 6 in Makevars anyway, even if it's 
| just to save users from using C++11 constructs and then wondering why 
| their packages fail on CRAN/winbuilder? In my case it also saves me from 
| recompiling "all of CRAN" (at least for now); that's a nice side effect, 
| but the first part also looks important to me.

It's a fair, and open, question.

We may, and then we may get away with not rebuilding; or we may not, but then
have to pay by rebuilding all.

I am somewhat surprised I haven't been asked to rebuild Debian packages.
There too we do have binary depends on C++ packages from CRAN, ie r-cran-rcpp
and r-cran-dplyr and whatnot.  But then ... then Debian archive managers now
just do 'binary rebuilds' as needed and I may be out of the loop.

Sorry but I just don't have much better information. There are Debian Wiki
pages on g++ transitions...

Dirk
George N. White III
#
On Sat, Nov 12, 2016 at 7:41 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

            

      
      
      
    

        
The fact that many current R installations use gcc-5 may be incentive
enough for packagers to avoid C++11 constructs.  In my limited gcc-6
experience, the main issue has been libraries that rely on  coding
practices
that were allowed by gcc-5 but are not allowed by gcc-6 defaults
such as "code that tries to check for stream errors by comparing to NULL or
0":

    if (file != NULL)

            

      
      
      
    

        
Unless intractable problems arise, wider use of gcc-6 outside of LTS
releases
should be encouraged.

            

      
      
      
    

        
It is worth noting that the macports default is to build R with gcc6, so
Ubuntu 16.10
is not alone in using gcc-6.  If gcc-6 was a disaster, there would be bug
reports by
now.  This says nothing about package authors using gcc-6 specific code in
new
work, but one hopes authors will test on LTS releases or at least response
to bug
reports from LTS users.

https://cran.r-project.org/bin/linux/ubuntu/README.html says there is
support
for Yakkety Yak, but the sample sources.list lines lack an entry for
yakkety.
This may result in users mixing gcc-5 R with gcc-6 libraries so needs to be
clarified.  Rather the provide a list of similar lines, why not one line:

deb https://<my.favorite.cran.mirror>/bin/linux/ubuntu <release>/


and mention ways to determine the release name.  One way is from /etc/apt
list files,
which works for derivatives such as Linux MINT.   I have seen instances
where a user
tried to use an older R disto in the the hope of avoiding rebuilding
existing libraries, so it
may be worth adding some sanity check to R to warn when R is run under a
release
that is newer than the build release.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 13 November 2016 at 09:32, George N. White III wrote:

        
| Unless intractable problems arise, wider use of gcc-6 outside of LTS releases
| should be encouraged.

That is being done, and has been done for years. Ie gcc-7 just got into
Debian unstable but BDR has been testing with it for a while now. Ditto with
gcc-6 when it was bleeding fresh.

There is nothing you can prescribe here. We are all caught between the
dimwitted enterprises with RHEL versions built by the Romans deploying
gcc-4.4, and these shiny newer things at the other side.

All we can do is test the crap out of it, and we do! Services like rhub help.
And of course developers willing to go the extra mile.  And tools like Docker
make it _trivial_ to keep another build environment, compiler version,
compiler tooling (UBSAN !!) etc pp

| is not alone in using gcc-6.? If gcc-6 was a disaster, there would be bug

We would have known a year or longer ago.  It has been a default in Debian
unstable and testing for a pretty long time.

| https://cran.r-project.org/bin/linux/ubuntu/README.html says there is support
| for Yakkety Yak, but the sample sources.list lines lack an entry for yakkety.

The rest of your post conflates these issue with what ill-educated users on
derivative distros we do not (formally, lack of volunteers) support.

There is Debian support on CRAN thanks to tireless effort by Johannes, and
Ubuntu support thanks to Michael.  If someone breaks his Mint box in despair
by going out of distro it is really their problem.  We can't fix all possible
installations for all people.

We aim to cover the main ones here, and I dare say we do pretty well --- but
alarmist posts don't help. I know you mean well but some things needed
clarification.   For background,  distros which know what they are doing have
transition plans.  See eg these from Debian

        https://wiki.debian.org/GCC6
        https://wiki.debian.org/GCC5  (just for reference)

Dirk