Skip to content

Linking to the BH package introduces CRAN warnings

17 messages · Romain Francois, Hadley Wickham, kaveh +1 more

#
Dear all,

I'm working on a project that links to the BH package
(http://cran.r-project.org/web/packages/BH/index.html).

My packages doesn't call entry points which might terminate R nor
write to stdout/stderr instead of to the console.

However, it seems some of the codes in the BH package
might. At any rate, when I include some boost headers such as
boost/math/distributions/ through BH, I get the following warnings
  when  submitting to the win-builder page:


   Found '_ZSt4cerr', possibly from 'std::cerr' (C++)

   Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)

   Found '_ZSt4cerr', possibly from 'std::cerr' (C++)

   Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)


  Furthermore, these warnings disappear when remove the boost
  headers and replace the call to boost functions by constants.

Looking at the CRAN-check diagnostics of some other packages that link to
BH, I do not see similar warnings, so I suppose it is possible to fix 
this issue.
Looking at their source code, it is not clear to me how these authors have
managed to do this, but this might be because I'm not that familiar with
boost to begin with. Can someone point me to some solution to this problem?

Thanks in advance,
#
On 4 November 2014 at 14:37, kaveh wrote:
| Dear all,
| 
| I'm working on a project that links to the BH package
| (http://cran.r-project.org/web/packages/BH/index.html).
| 
| My packages doesn't call entry points which might terminate R nor
| write to stdout/stderr instead of to the console.
| 
| However, it seems some of the codes in the BH package
| might. At any rate, when I include some boost headers such as
| boost/math/distributions/ through BH, I get the following warnings
|   when  submitting to the win-builder page:
| 
| 
|    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| 
|    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| 
|    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| 
|    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| 
| 
|   Furthermore, these warnings disappear when remove the boost
|   headers and replace the call to boost functions by constants.
| 
| Looking at the CRAN-check diagnostics of some other packages that link to
| BH, I do not see similar warnings, so I suppose it is possible to fix 
| this issue.
| Looking at their source code, it is not clear to me how these authors have
| managed to do this, but this might be because I'm not that familiar with
| boost to begin with. Can someone point me to some solution to this problem?

Briefly:

i) Your subject line is wrong.  You do not "link" to BH, you use it to
include headers at compile time. That may seem like a small difference, but
it is not. You generally want to avoid linking as much as you can, if only
for cross-OS portability,

ii) This the R-devel list for R question. You have a package question. You
are generally advised to contact __the package authors__ and/or the package
mailing list. And yes, BH has one in

    http://lists.r-forge.r-project.org/pipermail/boostheaders-devel/

though I grant you that it is not as well advertised as it should be. I just
opened a ticket at https://github.com/eddelbuettel/bh/issues/3 to remind
myself to improve that.

iii) As for your problem, only you and some careful bisections can help you
there as we do not have your sources.  I too have packages including BH
headers, but they do not pull in abort() or other things the CRAN gatekeepers
prohibit us from deploying.

Dirk
aka your friendly neighborhood BH maintainer
#
You?re kind of out of luck. These functions are both:
 - used by the boost headers
 - forbidden by R, well at least forbidden by CRAN
How would you not expect someone to be confused when ? not linking to ? BH requires the use of the `LinkingTo: BH` in the DESCRIPTION file.
#
Dear Romain,



                /You?re kind of out of luck. These functions are both:
                  - used by the boost headers
                  - forbidden by R, well at least forbidden by CRAN
                /

//

Thanks for conforming my earlier fears. Since I only use
this header and would like my package to eventually be
on CRAN, I was thinking of bypassing BH and just putting
these headers in the /inst directory and modifying them
to remove the offending calls. I was wondering what your
view on this is. Or perhaps there is a simpler alternative?

Thanks in advance,
On 2014-11-04 21:46, Romain Fran?ois wrote:

  
  
#
If you go through the hoops of modifying these headers to fulfill R?s requirements, I?m sure it would be of interest to others if you contribute these back to BH. 

The danger obviously is that this gets out of sync with boost, which would create work for merging your changes to new boost files from the future. 

Some parts of boost (e.g. uBlas) have macros to control whether or not std::cerr is used at all. https://github.com/eddelbuettel/bh/blob/cb1427c27dc068c8328fd1d2f4b1b8a8da1957c2/inst/include/boost/numeric/ublas/exception.hpp#L215 <https://github.com/eddelbuettel/bh/blob/cb1427c27dc068c8328fd1d2f4b1b8a8da1957c2/inst/include/boost/numeric/ublas/exception.hpp#L215>

But I don?t think this is of any relevance to the files you want to use. 

Romain

  
  
#
Dear Romain,


Thanks for all these info,


I will ponder this versus using
some of the alternatives in the R sources


Best regards,
On 2014-11-04 22:01, Romain Fran?ois wrote:

  
  
#
Maaaaybe - I had this note in RSQLite, and CRAN seemed ok with my explanation:

* checking compiled code ... NOTE
  File ?/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so?:
    Found ?___stderrp?, possibly from ?stderr? (C)
      Object: ?sqlite-all.o?

  This is in C code from the embedded SQLite database.


Hadley
#
Dear Hadley,

Thank you for this information, maybe the CRAN gods
will look favourably on this case too,


Best regards,
On 2014-11-04 23:32, Hadley Wickham wrote:
#
Gentlemen,
On 4 November 2014 at 23:36, kaveh wrote:
| Dear Hadley,
| 
| Thank you for this information, maybe the CRAN gods
| will look favourably on this case too,

You seemed to have missed a point my earlier email tried to stress: Inclusion
of BH does not lead to the warning.  

All this depends on WHICH headers are included, and the OP will need to sort
this out by modifying his code.

Dirk
 
| Best regards,
|
| On 2014-11-04 23:32, Hadley Wickham wrote:
| >>> | However, it seems some of the codes in the BH package
| >>> | might. At any rate, when I include some boost headers such as
| >>> | boost/math/distributions/ through BH, I get the following warnings
| >>> |   when  submitting to the win-builder page:
| >>> |
| >>> |
| >>> |    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >>> |
| >>> |    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| >>> |
| >>> |    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| >> You?re kind of out of luck. These functions are both:
| >>   - used by the boost headers
| >>   - forbidden by R, well at least forbidden by CRAN
| > Maaaaybe - I had this note in RSQLite, and CRAN seemed ok with my explanation:
| >
| > * checking compiled code ... NOTE
| >    File ?/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so?:
| >      Found ?___stderrp?, possibly from ?stderr? (C)
| >        Object: ?sqlite-all.o?
| >
| >    This is in C code from the embedded SQLite database.
| >
| >
| > Hadley
| >
|
#
Sire,

The header that is included is

boost/math/distributions/

If I remove it and replace the calls
to its members by plain constants,
the warning disappear (I just tried
this again on http://win-builder.r-project.org/).

This leads me to the suspicion that
the header is causing the error message.

I will post a simpler source code,
tomorrow on this list.

Best regards,
On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
#
Dear all,


the simple code in below, when send to the
win-builder returns the following (and no other)
warning:


* checking compiled code ... WARNING
File 'quicky/libs/i386/quicky.dll':
   Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
     Object: 'quicky.o'
   Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
     Object: 'quicky.o'
File 'quicky/libs/x64/quicky.dll':
   Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
     Object: 'quicky.o'
   Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
     Object: 'quicky.o'

Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor the C RNG.

See 'Writing portable packages' in the 'Writing R Extensions' manual.


Here is the source:

#include <algorithm>
#include <cstdlib>
#include <ctime>
#include <functional>
#include <fstream>
#include <iostream>
#include <math.h>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <sstream>
#include <vector>
#include <random>

#include <boost/math/distributions/normal.hpp>
#include <boost/math/distributions/chi_squared.hpp>

#include <Eigen/Dense>

using namespace std;
using namespace Eigen;
using Eigen::MatrixXd;
using Eigen::VectorXd;
using Eigen::VectorXi;
using Eigen::RowVectorXd;


using boost::math::chi_squared;
using boost::math::quantile;
using boost::math::complement;
using boost::math::normal_distribution;
using namespace boost::math::policies;

typedef policy<
       promote_double<true>
       > my_policy_norm;
typedef policy<
       promote_double<true>
       > my_policy_chi2;

typedef boost::math::normal_distribution<double,my_policy_norm> my_norm;
typedef boost::math::chi_squared_distribution<double,my_policy_chi2> 
my_chi2;


VectorXd GetQs(const VectorXd& x){
     const int n=x.size();
     double mytol=1e-8;
     double the_max=x.maxCoeff();
     double the_min=x.minCoeff();
     double the_rag=(the_max-the_min);
     if(the_rag<mytol)    return(x);
     if(1.0-the_max<mytol)    return(x);
     if(the_min<mytol)    return(x);
     VectorXd y=x.array();
     for(int i=0;i<n;i++) 
y(i)=sqrt(quantile(complement(my_chi2(1.0),x(i))));
     return(y);
}
extern "C"{
     void quicky(int* rn,double* xi,double* yi){
         const int n=*rn;
         VectorXd x=Map<VectorXd>(xi,n);
         Map<VectorXd>(yi,n)=GetQs(x);
     }
}


So I guess, I should fill a bug report with the
BH maintainer?

Best regards,
On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
#
On 5 November 2014 at 00:55, kaveh wrote:
| Dear all,
| 
| 
| the simple code in below, when send to the
| win-builder returns the following (and no other)
| warning:
| 
| 
| * checking compiled code ... WARNING
| File 'quicky/libs/i386/quicky.dll':
|    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
|      Object: 'quicky.o'
|    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
|      Object: 'quicky.o'
| File 'quicky/libs/x64/quicky.dll':
|    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
|      Object: 'quicky.o'
|    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
|      Object: 'quicky.o'
| 
| Compiled code should not call entry points which might terminate R nor
| write to stdout/stderr instead of to the console, nor the C RNG.
| 
| See 'Writing portable packages' in the 'Writing R Extensions' manual.
| 
| 
| Here is the source:
| 
| #include <algorithm>
| #include <cstdlib>
| #include <ctime>
| #include <functional>
| #include <fstream>
| #include <iostream>
| #include <math.h>
| #include <time.h>
| #include <stdio.h>
| #include <stdlib.h>
| #include <sstream>
| #include <vector>
| #include <random>
| 
| #include <boost/math/distributions/normal.hpp>
| #include <boost/math/distributions/chi_squared.hpp>
| 
| #include <Eigen/Dense>
| 
| using namespace std;
| using namespace Eigen;
| using Eigen::MatrixXd;
| using Eigen::VectorXd;
| using Eigen::VectorXi;
| using Eigen::RowVectorXd;
| 
| 
| using boost::math::chi_squared;
| using boost::math::quantile;
| using boost::math::complement;
| using boost::math::normal_distribution;
| using namespace boost::math::policies;
| 
| typedef policy<
|        promote_double<true>
|        > my_policy_norm;
| typedef policy<
|        promote_double<true>
|        > my_policy_chi2;
| 
| typedef boost::math::normal_distribution<double,my_policy_norm> my_norm;
| typedef boost::math::chi_squared_distribution<double,my_policy_chi2> 
| my_chi2;
| 
| 
| VectorXd GetQs(const VectorXd& x){
|      const int n=x.size();
|      double mytol=1e-8;
|      double the_max=x.maxCoeff();
|      double the_min=x.minCoeff();
|      double the_rag=(the_max-the_min);
|      if(the_rag<mytol)    return(x);
|      if(1.0-the_max<mytol)    return(x);
|      if(the_min<mytol)    return(x);
|      VectorXd y=x.array();
|      for(int i=0;i<n;i++) 
| y(i)=sqrt(quantile(complement(my_chi2(1.0),x(i))));
|      return(y);
| }
| extern "C"{
|      void quicky(int* rn,double* xi,double* yi){
|          const int n=*rn;
|          VectorXd x=Map<VectorXd>(xi,n);
|          Map<VectorXd>(yi,n)=GetQs(x);
|      }
| }
| 
| 
| So I guess, I should fill a bug report with the
| BH maintainer?

Err, why? BH does nothing wrong. 

You are NOT forced or required to use the Boost distributions header __as R
comes with the equivalent functionality__ via the Rmath.h header file from R.
Which has functionality that Rcpp provides to you in scalar and vector form.

And there are probably several dozen examples of using the R distribution
functions from Rcpp.

So this is _precisely_ what I suggested several mails ago: do your homework,
identify which header is causing it.  And the obvious next step is then to
not use the header.

Dirk
 

| Best regards,
| 
|
| On 2014-11-04 23:52, Dirk Eddelbuettel wrote:
| > Gentlemen,
| >
| > On 4 November 2014 at 23:36, kaveh wrote:
| > | Dear Hadley,
| > |
| > | Thank you for this information, maybe the CRAN gods
| > | will look favourably on this case too,
| >
| > You seemed to have missed a point my earlier email tried to stress: Inclusion
| > of BH does not lead to the warning.
| >
| > All this depends on WHICH headers are included, and the OP will need to sort
| > this out by modifying his code.
| >
| > Dirk
| >   
| > | Best regards,
| > |
| > | On 2014-11-04 23:32, Hadley Wickham wrote:
| > | >>> | However, it seems some of the codes in the BH package
| > | >>> | might. At any rate, when I include some boost headers such as
| > | >>> | boost/math/distributions/ through BH, I get the following warnings
| > | >>> |   when  submitting to the win-builder page:
| > | >>> |
| > | >>> |
| > | >>> |    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| > | >>> |
| > | >>> |    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| > | >>> |
| > | >>> |    Found '_ZSt4cerr', possibly from 'std::cerr' (C++)
| > | >>> |
| > | >>> |    Found 'abort', possibly from 'abort' (C), 'runtime' (Fortran)
| > | >> You?re kind of out of luck. These functions are both:
| > | >>   - used by the boost headers
| > | >>   - forbidden by R, well at least forbidden by CRAN
| > | > Maaaaybe - I had this note in RSQLite, and CRAN seemed ok with my explanation:
| > | >
| > | > * checking compiled code ... NOTE
| > | >    File ?/Users/hadley/Documents/databases/RSQLite.Rcheck/RSQLite/libs/RSQLite.so?:
| > | >      Found ?___stderrp?, possibly from ?stderr? (C)
| > | >        Object: ?sqlite-all.o?
| > | >
| > | >    This is in C code from the embedded SQLite database.
| > | >
| > | >
| > | > Hadley
| > | >
| > |
| >
|
#
Dear,

I was expecting this reaction.

Please do not get caught up in the details of the examples,
which I have tried to make as simple as possible for your
benefit.

The main point is that if you remove the lines associated
with

boost/math/distributions/


the warning disappears as well. Ergo,

boost/math/distributions/

is causing the warnings.

Best regards,
On 2014-11-05 13:43, Dirk Eddelbuettel wrote:
#
Envoy? de mon iPhone
Calls to these forbidden fruits come from the BH tree so ...
So why these headers are shipped with BH then.
#
On 5 November 2014 at 13:54, kaveh wrote:
| Dear,
| 
| I was expecting this reaction.
| 
| Please do not get caught up in the details of the examples,
| which I have tried to make as simple as possible for your
| benefit.

Well, to be perfectly honst, there you failed. 

No need to carry RcppEigen for example.  "Minimally reproducible" is how
describe ideal examples.
 
| The main point is that if you remove the lines associated
| with
| 
| boost/math/distributions/
| 
| 
| the warning disappears as well. Ergo,
| 
| boost/math/distributions/
| 
| is causing the warnings.

Yes, and I suggested to you to remove these lines, and offered you an easy
alternative already provided by the R system in which you are trying to craft
your extension.

I mentioned in my first email that I thought your post was probably off-topic
for r-devel.  You have now posted six more times to this list.  I would urge
to consider if it really the most appropropriate venue for this.

Hope this helps,  Dirk
#
On 5 November 2014 at 14:11, Romain Francois wrote:
| > Le 5 nov. 2014 ? 13:43, Dirk Eddelbuettel <edd at debian.org> a ?crit :
| > You are NOT forced or required to use the Boost distributions header __as R
| > comes with the equivalent functionality__ via the Rmath.h header file from R.
| > Which has functionality that Rcpp provides to you in scalar and vector form.
| > 
| > And there are probably several dozen examples of using the R distribution
| > functions from Rcpp.
| > 
| > So this is _precisely_ what I suggested several mails ago: do your homework,
| > identify which header is causing it.  And the obvious next step is then to
| > not use the header.
| 
| So why these headers are shipped with BH then. 

The BH "builder" (ie the script local/scripts/CreateBoost.sh in the repo)
actively selects a number of Boost libraries [1], and uses the Boost tool
'bcp' to copy these (header-only) libraries -- plus all their dependencies.
The set of "selected components" grew out of initial requirements, plus
requests received since the package was created.  [2]

Now, just because some files within a library tickle a warning does not seem
to imply that all use of said warning is impossible. By my count, over two
dozen CRAN packages currently depend on BH [3] indicating some usefulness of BH,
including to the dplyr package you work on.

Policies and requirements do of cause charge, but I am not aware of any of
the two dozen package tickling this issue -- their use case is just fine,
thank you, and their requirements lead to the inclusion of the header
currently comprised in the package.

I hope this answers your question. Should you have further questions
concerning the BH package, could you be so kind as to bringing them to
appropriate list [4] or filing a ticket on GH?

Thanks, Dirk

[1] "components" may be a better term so we avoid the association with "linking"
[2] Another one of these requests just came in this week asking for circular_buffer.
[3] http://cran.r-project.org/web/packages/BH/index.html
[4] http://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/boostheaders-devel
#
Yeah so that?s like ? we?ll sell you horticultural bulbs, but only use them for indoor culture of tomatoes, ?cause you know it?s illegal to grow weed ? whatever. 

Believe me, I?d love for dplyr not to depend on BH, which we use for unordered_map.
This was not really a question, so yes I guess it answers it. Not your fault, just the user?s fault of using something that is shipped yet is unusable. You?re in the clear.