[Rquantlib-devel] RQuantLib fixed-income discussion (Re: 1 Rquantlib-devel moderator request(s) waiting)

Michele Salvadore michele.salvadore at gmail.com
Fri Oct 10 08:51:17 CEST 2014


On 9 October 2014 16:23, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> On 9 October 2014 at 15:55, Michele Salvadore wrote:
> | On 9 October 2014 13:26, Dirk Eddelbuettel <edd at debian.org> wrote:
> |     Now it turns out that the suggested change breaks the Travis
> auto-builder.
> |     That is something to avoid as we set up continuous integration to
> catch
> |     these
> |     things. The error happens right at the top of R CMD check:
> |
> |       * checking whether package ‘RQuantLib’ can be installed ... ERROR
> |       Installation failed.
> |       See ‘/home/travis/build/eddelbuettel/rquantlib/RQuantLib.Rcheck/
> |     00install.out’ for details.
> |
> |     But I don;t have access to the log...
> |
> |     I also note that you switched to using auto -- RQuantLib is not
> (yet?) a
> |     C++11 project, and it may good to not force that just yet.
> |
> |
> | I thought C++11 had to be switched on already in order to support for
> long long
> | type, see your comment here:
> |
> http://lists.r-forge.r-project.org/pipermail/rquantlib-devel/2014-September/
> | 000015.html
>
> It was a guess of mine, the code may also fail to build for other reasons.
>
> But I think it would be preferable for you to keep the repo buildable ;-)
> So let's fix this now before adding further pull requests, or expanding the
> current one.
>

totally agree, it was indeed my intention to push only buildable commits :/


> | Sorry about that, will revert to use explicit types.
> | In regards to the build I apologize, unfortunately I am stuck on a
> windows box
> | for this project and I am struggling a bit with the platform. Any chance
> you
> | recall how the win-builder get around the issue with the long long type
> | discussed in the thread above without -std=c++0x?
>
> win-builder has not changed in a while, and RQuantLib passed all tests when
> uploaded.  CRAN also continues to build and test once released --- the best
> of why knowledge would be encoded on src/Makevars.win.  And as you can see
> there are no particular switches.
>
> Can you remind me what the issue is, then?   Boost usage from R tends to
> issue copious __warnings__ about long long but still builds.  I may have
> been
> refering to suppressing the warning by turning on C++11, but I am not doing
> that yet for RQuantLib.
>

 Sure: in order to get my build rolling and the windows box I had to add
the following switches on src/Makevars.win:

PKG_CXXFLAGS=-I$(QUANTLIB_ROOT) -I../inst/include -I. -I$(BOOSTLIB)
$(SHLIB_OPENMP_CFLAGS) -std=c++0x
PKG_LIBS=-L$(QUANTLIB_ROOT)/lib${R_ARCH} -lQuantLib $(SHLIB_OPENMP_CFLAGS)
-Wl,--allow-multiple-definition

(the $(SHLIB_OPENMP_CFLAGS) and $(SHLIB_OPENMP_CFLAGS) get the openMP
pragma warnings out of the way)

without the -Wl,--allow-multiple-definition the linker is not happy, as it
produces a huge amount of multiple definition errors like the following one:

asian.o:asian.cpp:(.text+0x2f20): multiple definition of `SEXPREC*
Rcpp::wrap<QuantLib::Date>(QuantLib::Date const&)'
RcppExports.o:RcppExports.cpp:(.text+0x4250): first defined here

If I also switch off -stdC++0x, the compilation fails because of "invalid
conversion from 'SEXP' to 'long long unsigned int":

g++ -m64 -I"C:/PROGRA~1/R/R-31~1.1/include"       -I"C:/Program
Files/R/R-3.1.1/library/Rcpp/include"
-I"d:/RCompile/CRANpkg/extralibs64/local/include"
 -I"C:/workspace/lib/QuantLib/Quantlib14" -I../inst/include -I.
-I"C:/workspace/lib/boost/boost_1_56_0" -fopenmp   -O3 -Wall  -mtune=core2
  -c RcppExports.cpp -o RcppExports.o
In file included from C:/Program
Files/R/R-3.1.1/library/Rcpp/include/Rcpp/as.h:25:0,
                 from C:/Program
Files/R/R-3.1.1/library/Rcpp/include/RcppCommon.h:169,
                 from ../inst/include/rquantlib_internal.h:30,
                 from ../inst/include/RQuantLib.h:23,
                 from RcppExports.cpp:4:
C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/internal/Exporter.h:
In constructor 'Rcpp::traits::Exporter<T>::Exporter(SEXP) [with T = long
long unsigned int, SEXP = SEXPREC*]':
C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/as.h:79:51:
instantiated from 'T Rcpp::internal::as(SEXP,
Rcpp::traits::r_type_generic_tag) [with T = long long unsigned int, SEXP =
SEXPREC*]'
C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/as.h:144:84:
instantiated from 'T Rcpp::as(SEXP) [with T = long long unsigned int, SEXP
= SEXPREC*]'
C:/Program
Files/R/R-3.1.1/library/Rcpp/include/Rcpp/InputParameter.h:34:45:
instantiated from 'Rcpp::InputParameter<T>::operator T() [with T = long
long unsigned int]'
RcppExports.cpp:29:161:   instantiated from here
C:/Program
Files/R/R-3.1.1/library/Rcpp/include/Rcpp/internal/Exporter.h:31:31: error:
invalid conversion from 'SEXP' to 'long long unsigned int' [-fpermissive]

The latter can be turned into a warning with the flag -fpermissive, is that
the way to go? I am not sure as in the Makevars.win there is neither.

I am going to branch out my commits in my github and try to get the CI on
travis working before merging back, but it would be really useful to access
that log file...




> Hope this clarifies things and helps,  Dirk
>
>
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rquantlib-devel/attachments/20141010/f4652f6e/attachment.html>


More information about the Rquantlib-devel mailing list