[Rcpp-devel] RcppEigen-related compilation error for Windows i386

[Evan Biederstedt]

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.biederstedt at 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 <edd at 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 | edd at debian.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20200920/913c1809/attachment.html>