Hey there The thing that remains extremely puzzling to me is that using `Linking to: Rcpp, RcppEigen` (without the RcppSpdlog calls), it compiles correctly on i386. I've created a branch here: https://github.com/kharchenkolab/N2R/tree/without_RcppSpdlog
https://win-builder.r-project.org/04120gdc336K/ It compiles correctly, and the package words as intended. Why would including `Linking to: Rcpp, RcppEigen, RcppSpdlog` result in these 32-bit/64-bit errors, in particular that RcppEigen error? It's a bit strange---I'll keep looking into this. On Sun, Sep 20, 2020 at 12:34 AM Evan Biederstedt < evan.biederst...@gmail.com> wrote: > Hey Dirk > > I really appreciate the help here. I've been trying this via Mac OS with > VMWare Fusion using a Windows 10 32-bit ISO. (Yeesh, it's slow.) > > > 1. You get an R CMD check warning on use of stderr. That is > understandable as > you included _upstream_ spdlog. It will do that. Once you instrument it the > way RcppSpdlog does, this issue goes away. The change is minimal as we can > simply create the 'r_sink_mt' instance we need in the Hnsw constructor. I > will send you a PR for that in a minute. > > > Yes, this is entirely correct. Although the spdlog library installs > successfully, I would love to use RcppSpdlog to get rid of the stderr > warning. > > RcppSpdlog does precisely what I need here :) Thank you > > > 2. The 32bit issue. I have not yet looked into this but it might be best > to > disentangle this. As I mentioned, _maybe_ we need to switch to int64_t > use. Very very worst case you could simply disable the code via #define and > state that 'legacy systems' will no longer be supported ;-). I am > half-kidding here but it is an option. Nobody is running your genomics > workload on systems from 15 years ago so .. > > > I have no successful updates, sadly. I'm using int64_t for every `int` > here: https://github.com/kharchenkolab/N2R/blob/master/src/n2knn.cpp > I still get this error. > > What's difficult for me is that it's only RcppEigen code, so I'm finding > it a bit difficult to trace back where the issue is. > > I guess the next step could be explicitly made every 'int' in the /src > int64_t... > > I'd also be very welcome to disable code for 32-bit systems, if CRAN would > allow this. I think a warning message suggesting developers no longer > support this is entirely appropriate. :) > > Best, Evan > > > > On Sat, Sep 19, 2020 at 6:25 PM Dirk Eddelbuettel <e...@debian.org> wrote: > >> >> Evan, >> >> As you posted a link to the repo, I took a look -- given my recent work on >> RcppSpdlog this was of obvious interest. >> >> Now, as I understand it, you are fighting two battles here: >> >> 1. You get an R CMD check warning on use of stderr. That is >> understandable as >> you included _upstream_ spdlog. It will do that. Once you instrument it >> the >> way RcppSpdlog does, this issue goes away. The change is minimal as we >> can >> simply create the 'r_sink_mt' instance we need in the Hnsw constructor. I >> will send you a PR for that in a minute. >> >> 2. The 32bit issue. I have not yet looked into this but it might be best >> to >> disentangle this. As I mentioned, _maybe_ we need to switch to int64_t >> use. Very very worst case you could simply disable the code via #define >> and >> state that 'legacy systems' will no longer be supported ;-). I am >> half-kidding here but it is an option. Nobody is running your genomics >> workload on systems from 15 years ago so ... >> >> Cheers, Dirk >> >> -- >> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >> >
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
