<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 11 October 2014 21:13, Dirk Eddelbuettel <span dir="ltr"><<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Michele,<br>
<br>
Sorry, missed this email earlier.<br>
<span class=""><br>
On 10 October 2014 at 08:51, Michele Salvadore wrote:<br>
|<br>
| On 9 October 2014 16:23, Dirk Eddelbuettel <<a href="mailto:edd@debian.org">edd@debian.org</a>> wrote:<br>
|<br>
</span><span class="">| win-builder has not changed in a while, and RQuantLib passed all tests when<br>
| uploaded. CRAN also continues to build and test once released --- the best<br>
| of why knowledge would be encoded on src/Makevars.win. And as you can see<br>
| there are no particular switches.<br>
|<br>
| Can you remind me what the issue is, then? Boost usage from R tends to<br>
| issue copious __warnings__ about long long but still builds. I may have<br>
| been<br>
| refering to suppressing the warning by turning on C++11, but I am not doing<br>
| that yet for RQuantLib.<br>
|<br>
| Sure: in order to get my build rolling and the windows box I had to add the<br>
| following switches on src/Makevars.win:<br>
|<br>
| PKG_CXXFLAGS=-I$(QUANTLIB_ROOT) -I../inst/include -I. -I$(BOOSTLIB) $<br>
| (SHLIB_OPENMP_CFLAGS) -std=c++0x<br>
| PKG_LIBS=-L$(QUANTLIB_ROOT)/lib${R_ARCH} -lQuantLib $(SHLIB_OPENMP_CFLAGS)<br>
| -Wl,--allow-multiple-definition<br>
<br>
</span>That is a little strange, and I have no lead.<br>
<br>
In essence, QuantLib and Boost have not changed, and CRAN was able to process<br>
the QuantLib 1.4-based rebuild just fine.<br>
<span class=""><br>
| (the $(SHLIB_OPENMP_CFLAGS) and $(SHLIB_OPENMP_CFLAGS) get the openMP pragma<br>
| warnings out of the way)<br>
|<br>
| without the -Wl,--allow-multiple-definition the linker is not happy, as it<br>
| produces a huge amount of multiple definition errors like the following one:<br>
|<br>
| asian.o:asian.cpp:(.text+0x2f20): multiple definition of `SEXPREC* Rcpp::wrap<br>
| <QuantLib::Date>(QuantLib::Date const&)'<br>
| RcppExports.o:RcppExports.cpp:(.text+0x4250): first defined here<br>
<br>
</span>Oh, I am starting the smell the bacon. My thinking was faulty.<br>
<br>
The previous builds all passed -- it was still the old code setup. Since then<br>
I have changed the code to switch to using Rcpp Attributes and newer Rcpp<br>
features, and nobody had tried that on Windows before you did!<br>
<br>
So there may well be something going on with Windows.<br>
<br>
That said, everything I committed passed under Travis CI on Linux, as well as<br>
(of course) on my Linux box.<br>
<span class=""><br>
| If I also switch off -stdC++0x, the compilation fails because of "invalid<br>
| conversion from 'SEXP' to 'long long unsigned int":<br>
<br>
</span>Ok, the recent changes may well require this.<br>
<br>
We have plugins for Rcpp which will get R to select -std=c++0x (on Windows,<br>
using g++-4.6.*) and -std=c++11 (on Linux and OS X).<br>
<br>
So for now do keep this in src/Makevars.win<br>
<div><div class="h5"><br>
| g++ -m64 -I"C:/PROGRA~1/R/R-31~1.1/include" -I"C:/Program Files/R/R-3.1.1<br>
| /library/Rcpp/include" -I"d:/RCompile/CRANpkg/extralibs64/local/include" -I"C:<br>
| /workspace/lib/QuantLib/Quantlib14" -I../inst/include -I. -I"C:/workspace/lib/<br>
| boost/boost_1_56_0" -fopenmp -O3 -Wall -mtune=core2 -c RcppExports.cpp -o<br>
| RcppExports.o<br>
| In file included from C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/<br>
| as.h:25:0,<br>
| from C:/Program Files/R/R-3.1.1/library/Rcpp/include/<br>
| RcppCommon.h:169,<br>
| from ../inst/include/rquantlib_internal.h:30,<br>
| from ../inst/include/RQuantLib.h:23,<br>
| from RcppExports.cpp:4:<br>
| C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/internal/Exporter.h: In<br>
| constructor 'Rcpp::traits::Exporter<T>::Exporter(SEXP) [with T = long long<br>
| unsigned int, SEXP = SEXPREC*]':<br>
| C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/as.h:79:51: instantiated<br>
| from 'T Rcpp::internal::as(SEXP, Rcpp::traits::r_type_generic_tag) [with T =<br>
| long long unsigned int, SEXP = SEXPREC*]'<br>
| C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/as.h:144:84: <br>
| instantiated from 'T Rcpp::as(SEXP) [with T = long long unsigned int, SEXP =<br>
| SEXPREC*]'<br>
| C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/InputParameter.h:34:45: <br>
| instantiated from 'Rcpp::InputParameter<T>::operator T() [with T = long long<br>
| unsigned int]'<br>
| RcppExports.cpp:29:161: instantiated from here<br>
| C:/Program Files/R/R-3.1.1/library/Rcpp/include/Rcpp/internal/Exporter.h:31:31:<br>
| error: invalid conversion from 'SEXP' to 'long long unsigned int'<br>
| [-fpermissive]<br>
|<br>
| The latter can be turned into a warning with the flag -fpermissive, is that the<br>
| way to go? I am not sure as in the Makevars.win there is neither.<br>
|<br>
| I am going to branch out my commits in my github and try to get the CI on<br>
| travis working before merging back, but it would be really useful to access<br>
| that log file...<br>
<br>
</div></div>I don't want you stuck in a dead-end either. If you have your commits as a<br>
clean diff somewhere, I could at least try them here.<br>
<br>
We need to disentangle<br>
<br>
-- your issues on Windows, which may well be due to my code changes since<br>
the last release<br>
<br>
-- whether your commits build fine otherwise<br>
<br>
so that we can focus on 2) rather than 1)<br></blockquote><div><br></div><div>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.</div><div>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... </div><div><br></div><div>Cheers, Michele</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers, Dirk<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
<a href="http://dirk.eddelbuettel.com" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a><br>
</div></div></blockquote></div><br></div></div>