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

[Michele Salvadore]

On 11 October 2014 21:13, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> Michele,
>
> Sorry, missed this email earlier.
>
> On 10 October 2014 at 08:51, Michele Salvadore wrote:
> |
> | On 9 October 2014 16:23, Dirk Eddelbuettel <edd at debian.org> wrote:
> |
> |     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
>
> That is a little strange, and I have no lead.
>
> In essence, QuantLib and Boost have not changed, and CRAN was able to
> process
> the QuantLib 1.4-based rebuild just fine.
>
> | (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
>
> Oh, I am starting the smell the bacon. My thinking was faulty.
>
> The previous builds all passed -- it was still the old code setup. Since
> then
> I have changed the code to switch to using Rcpp Attributes and newer Rcpp
> features, and nobody had tried that on Windows before you did!
>
> So there may well be something going on with Windows.
>
> That said, everything I committed passed under Travis CI on Linux, as well
> as
> (of course) on my Linux box.
>
> | If I also switch off -stdC++0x, the compilation fails because of "invalid
> | conversion from 'SEXP' to 'long long unsigned int":
>
> Ok, the recent changes may well require this.
>
> We have plugins for Rcpp which will get R to select -std=c++0x (on Windows,
> using g++-4.6.*) and -std=c++11 (on Linux and OS X).
>
> So for now do keep this in src/Makevars.win
>
> | 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...
>
> I don't want you stuck in a dead-end either.  If you have your commits as a
> clean diff somewhere, I could at least try them here.
>
> We need to disentangle
>
>   -- your issues on Windows, which may well be due to my code changes since
>      the last release
>
>   -- whether your commits build fine otherwise
>
> so that we can focus on 2) rather than 1)
>

OK, the travis CI build passes now, I've pushed by commits upstream to the
pull request and the build was OK on your side as well finally. Let me know
what you think or the changes and if you can merge the pull request. If you
are good with that, I have additional changes ready which implement the
features I described earlier on.
For the time being, I am keeping the switches above on my box (actually I
am using -fpermissive rather than the c++0) in order to compile, but I
don't commit them upstream. I guess we will have to tackle this at some
point before a new windows release can be made available...

Cheers, Michele

>
> Cheers, 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/20141014/39621edf/attachment.html>