Skip to content

[R-pkg-devel] Compiler choice on CRAN (R-windows-oldrel)

5 messages · Mark van der Loo, Peter Dalgaard, Uwe Ligges

Original
Mark van der Loo
# 
Dear listers,


Compilation of my gower pkg fails on R-oldrel-windows. I am pretty sure
that this is because it uses gcc 4.6.3 which has limited support for OpenMP
(the errors are the same as I got on the old travis-ci build environment,
see my related question[1]).

Now, according to the Rtools page[2], since R3.2.2 "Both the gcc 4.6.3
toolchain and a toolchain based on gcc 4.9.3 and mingw-w64 v3 are now
included." Not sure what that says about CRAN, but I'm hoping/guessing it
uses Rtools the same way as we do.

So I guess I have the following options:

- make my package depend on R>=3.3
- Alter my code (as kindly suggested by Ott Toomet in [1])
- Tell CRAN to use the modern compiler.

Obviously, the latter would be easiest. Is this is even possible? For a
local installation I could set an environment variable[3], but how about
doing this at CRAN?

Thanks,
Mark


[1] https://stat.ethz.ch/pipermail/r-package-devel/2016q3/000983.html
[2] https://cran.r-project.org/bin/windows/Rtools/
[3]
https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
Peter Dalgaard
# 
I don't have hard info on ABI compatibility between gcc versions, but there have been issues in the past, at least with with gfortran.

Now, many people/schools will have R-3.2.x installed, built with gcc 4.6.y. We cannot retroactively recompile their installation, nor expect them to install a new version built with gcc 4.9.z. This raises a specific question and a generic one:

- specific: Will a package binary of gower built with 4.9 work with R built with 4.6?
- generic: Is is sufficiently likely that a given package if compiled with a different compiler version that CRAN would consider having a mechanism to specify a particular compiler version?

I suspect that the answer to the second question is no.

Whether to condition on R >= 3.3 is a good idea largely depends on two things

- the user base (would they upgrade R anyways?)
- are there other packages that depends on gower? (CRAN keeps only the newest version of a package so requiring a newer R could affect users with less aggressive update policies. This already happened when the pbkrtest package update rendered the car package unloadable.)

You do have a 4th option: conditionalize the _code_ on the R version, then remove old-style code when 3.2.x becomes history.

-pd
On 25 Aug 2016, at 11:20 , Mark van der Loo <mark.vanderloo at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Mark van der Loo
    

    

      
      #
    

  


  

      
Thank you Peter, good points.

Good to know for sure (or a.s.) that compiler specification at CRAN is not
an option. The 4th option is interesting as well. I may just do that.

Thanks again!
Mark









Op do 25 aug. 2016 om 12:17 schreef peter dalgaard <pdalgd at gmail.com>:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 25.08.2016 13:14, Mark van der Loo wrote:

            

      
      
      
    

        
For Windows, indeed, you are tight to gcc 4.6.3 for R < 3.3.0 and to gcc 
4.9.3 for R >= 3.3.0. If your package fails for gcc 4.6.3 we can live 
with it.

Same for the other platform CRAN runs checks for, typically there is one 
compiler (as specified on the CRAN web pages).

Best,
Uwe Ligges

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Mark van der Loo
    

    

      
      #
    

  


  

      
Thanks Uwe. Very clear.

I'll post the solution I chose, so people can find it later. The problem is
that GCC <= 4.6.3 (at least) does not implement OpenMP reduction statements.

So now I do something like this:

#ifdef _OPENMP
#include <omp.h>
#endif

#ifdef __GNUC__
#if __GNUC__ <= 4 & __GNUC_MINOR__ <= 6
#else
#define HAS_REDUCTION
#endif
#endif

/* more code */

  #ifdef HAS_REDUCTION
  #pragma omp parallel for reduction(min:imin), reduction(max:imax)
  #endif
  for (int i=0; i<nx; i++){
    /*loop content*/
  }


This means that the loop does not get parallelized on systems compiling
with gcc <= 4.6.x

Best,
Mark






Op do 25 aug. 2016 om 14:44 schreef Uwe Ligges <
ligges at statistik.tu-dortmund.de>: