Skip to content

[Rcpp-devel] Fwd: CRAN packages with C++ compilation errors on OS X 10.9

9 messages · Dominick Samperi, Dirk Eddelbuettel, Baptiste Auguie +1 more

Original
Baptiste Auguie
# 
Dear Rcpp gurus,

Today a CRAN maintainer informed us of the failure of a few Rcpp-related
packages to build under the new version of the Mac operating system, OS X
10.9 aka Mavericks.
I do have access to a Mac, but I'm reluctant (in fact, unable) to update to
Mavericks, therefore I'm in the dark when it comes to fixing /testing for
the errors reported in the log file. On a positive note, it appears at
first sight that most of the errors are relatively benign, and
similar-looking issues are reported for all the packages involved. That
gives me hope that once the underlying issue is well identified, most
packages can be fixed with minimal changes.

Here's the info we were given from CRAN,

"OS X 10.9 (aka Mavericks) has a new C++ compiler, clang++ with libcxx
headers/runtime.  Your package fails to compile with that compiler: see the
appropriate log at
http://www.stats.ox.ac.uk/pub/**bdr/Mavericks/<http://www.stats.ox.ac.uk/pub/bdr/Mavericks/>
 ."

My two packages are cda and planar. The error seems to occur in the Modules
definition, e.g. from this line in my code

https://github.com/baptiste/planar/blob/master/src/multilayer.cpp#L231

where "function" is judged ambiguous, as far as I understand. This
"function" is presumably something from
Rcpp/include/Rcpp/module/Module_generated_function.h
but I am not familiar with that code.

Any ideas, hints?

Best regards,

baptiste
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131031/e6377fdf/attachment.html>
Romain Francois
# 
Le 31/10/2013 15:59, baptiste auguie a ?crit :
I'll have a look. It is likely to be a bug in some part of Rcpp's code 
bloat.

I will try to find a solution that does not involve releasing a new Rcpp 
as 0.10.6 was just released.

Romain
Dirk Eddelbuettel
#
On 31 October 2013 at 16:18, Romain Francois wrote:
| I'll have a look. It is likely to be a bug in some part of Rcpp's code 
| bloat.

Thanks
 
| I will try to find a solution that does not involve releasing a new Rcpp 
| as 0.10.6 was just released.

Not a concern. If it is a bug, and it needs a fix and a new release, we will
make one.  These days the codebase is very good shape as the successful builds
at R-Forge show.

Dirk
Dominick Samperi
# 
Apple is rapidly moving away from gcc/g++ towards clang/clang++,
resulting in some tricky versioning issues. I tried to update to
Mavericks but had to backtrack due to technical problems (Paragon
NTFS filesystem support fails).

After reinstalling Mac OS X 10.8 and installing R for Mac OS I found
that "R CMD config CXX" returns "llvm-g++-4.2 -arch x86_64", but
llvm-g++-4.2 is not shipped with the latest version of
Xcode5/command line tools. This will obviously cause package
installs to fail. A work-around is to create a symbolic link to
/usr/bin/g++ (this will work until Apple no longer ships g++).

In general, what "R CMD config CXX" returns depends on the
value of CXX at the time R is built, and this may not be consistent
with your particular Mac OS environment (depends on OS version,
command line tools version, etc.)

Dominick



On Thu, Oct 31, 2013 at 11:18 AM, Romain Francois
<romain at r-enthusiasts.com>wrote:

            

      
      
      
    

        

      
      
    

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131031/8e15e5ad/attachment-0001.html>

  
  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
Le 31/10/2013 15:59, baptiste auguie a ?crit :

            

      
      
      
    

        
I sent you a pull request on github.

.function abuses the compiler recognition, it is just unfortunate that 
something else is called function, which is what confused it.

Not sure there could be defenses against it.

In the meantime, you should be fine by just using Rcpp::function


Also, for such trivial uses of modules (i.e. no classes), maybe it is 
worth considering using // [[Rcpp::export]] and code generation given by 
compileAttributes instead of modules.

Romain

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 31 October 2013 at 17:15, Romain Francois wrote:

        
| Le 31/10/2013 15:59, baptiste auguie a ?crit :
| > "OS X 10.9 (aka Mavericks) has a new C++ compiler, clang++ with libcxx
| > headers/runtime.  Your package fails to compile with that compiler: see
| > the appropriate log at http://www.stats.ox.ac.uk/pub/__bdr/Mavericks/
| > <http://www.stats.ox.ac.uk/pub/bdr/Mavericks/> ."
|
| I sent you a pull request on github.
| 
| .function abuses the compiler recognition, it is just unfortunate that 
| something else is called function, which is what confused it.
| 
| Not sure there could be defenses against it.
| 
| In the meantime, you should be fine by just using Rcpp::function

Can you think of a solution at our end that will work with existing code yet
also accomodates the newest clang version?  

If you check the 'bdr' URL above you will see that this affects 10 packages,
and I recognise several (though not all) as Rcpp users.
 
Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 31 October 2013 at 11:36, Dirk Eddelbuettel wrote:

        
| Can you think of a solution at our end that will work with existing code yet
| also accomodates the newest clang version?  

I take that back. Looking again at the BDR directory, I see a number of
compiles failing because 'rank' was defined, just how Baptiste got rosted for
'function'. 

That seems silly on the side of clang++, but it is best addressed on the user side.

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Baptiste Auguie
    

    

      
      #
    

  


  

      
On 31 October 2013 13:15, Romain Francois <romain at r-enthusiasts.com> wrote:

        

            

      
      
      
    

        
Thanks! I've merged your pull request, and will propagate the changes to my
cda package which reports similar issues.

            

      
      
      
    

        
You're probably right, I haven't been able to keep up with the new idioms
in Rcpp; next time I get around to developing the package for new
functionality, I'll investigate how to use those attributes instead.

Thanks!

baptiste

            

      
      
      
    

        

      
      
    

        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20131031/f0558fad/attachment.html>

  
  


  


      

    

    

      
      

        


  

        

      Romain Francois
    

    

      
      #
    

  


  

      
Le 31/10/2013 17:36, Dirk Eddelbuettel a ?crit :

            

      
      
      
    

        
Maybe. This seems to be related to the <functional> header. We use this 
only for unary_function and binary_function, e.g. :

template <typename T, typename OUT = SEXP>
     class unary_call : public std::unary_function<T,OUT> {

We don't really need those sa they are trivial classes just there for 
the purpose of adding some typedefs:

template <class Arg, class Result>
   struct unary_function {
     typedef Arg argument_type;
     typedef Result result_type;
   };

Easy to replicate without including functional.