Hi Dirk and friends Thanks for the help. In my attempt to isolate the issue, I wonder if there's an issue with linking to RcppSpdlog.
I tried compiling with "LinkingTo: Rcpp, RcppEigen, RcppSpdlog", and the error exists: https://win-builder.r-project.org/F2g5vjpw6M1T https://github.com/kharchenkolab/N2R/tree/341fe9ff37a0f3082e1daff03d4b01ecf03d83b2 But when I remove `RcppSpdlog`, it successfully compiles: https://win-builder.r-project.org/G0PRavw4yuhZ/ https://github.com/kharchenkolab/N2R/commit/fd49332c6c25655e0926b0935c9741ff8adcfecf Could this be some issues with linking to both RcppEigen and RcppSpdlog? Issues with RcppSpglog windows binaries? As some background, I was using the spdlog library directly, which compiles correctly on windows as well: https://github.com/kharchenkolab/N2R/tree/338f380df4c49da76c797f2e5a3791f978c64156 https://win-builder.r-project.org/ju94MKp8YSD5/ I wanted to switch to RcppSpdlog to stop the CRAN notes/warnings. *> That is worse. It seems to rely on 64bit layout. Yet is uses 'int' as opposed to 'int64_t' which would hardwire the size.> Is the 'int' under your control? Can you make that an int64_t?* So the above makes me wonder if there's an issue linking to RcppSpdlog and RcppEigen, because there are no issues with 64-bit otherwise. I'm not making extensive or complicated calls with spdlog either: https://github.com/kharchenkolab/N2R/blob/master/src/n2/hnsw.cc#L67-L71 Just 'spdlog::get()' and either 'spdlog::stdout_logger_mt()' (in the standard spdlog library) or 'spdlog::r_sink_mt()' (in the RcppSpdlog library). Hopefully the above is clear, and thanks for any insight. Best, Evan On Sat, Sep 19, 2020 at 1:01 PM Dirk Eddelbuettel <e...@debian.org> wrote: > > Hi Evan, > > On 19 September 2020 at 10:14, Evan Biederstedt wrote: > | I'm in the process uploading an R package to CRAN, which is a relatively > | simple interface to a C++ library: https://github.com/kharchenkolab/N2R > | > | The windows binaries just became available for RcppSpdLog, so I wanted to > | check how it installed on windows before CRAN submission. > | > | The package currently installs on Linux and Mac OS, but when I check with > | `devtools::check_win_devel()`, I'm getting a Windows-related error. > | > | The error appears to be related to RcppEigen, not the C++ library---this > | feels like something easily fixable, but I'm a bit nonplussed how to fix > | this: > | > | """ > | > | > d:/RCompile/CRANpkg/lib/4.1/RcppEigen/include/Eigen/src/Core/DenseCoeffsBase.h:650:34: > | warning: ignoring attributes on template argument > | 'Eigen::internal::packet_traits<int>::type' {aka '__vector(2) long > | long int'} [-Wignored-attributes] > | > | return > internal::first_aligned<int(unpacket_traits<DefaultPacketType>::alignment),Derived>(m); > | > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | make: *** [D:/RCompile/recent/R/etc/i386/Makeconf:244: n2knn.o] Error 1 > | ERROR: compilation failed for package 'N2R' > | * removing 'd:/RCompile/CRANguest/R-devel/lib/N2R' > | * restoring previous 'd:/RCompile/CRANguest/R-devel/lib/N2R' > | > | """ > | > | "'Eigen::internal::packet_traits<int>::type' {aka '__vector(2) long long > | int'} [-Wignored-attributes]" appears to be a somewhat standard warning, > > Right. Eigen is very verbose. For my local compilations I often set > something > like this in ~/.R/Makevars (uncommented, of course, and later in the file > used in CXX*FLAGS): > > #PEDANTIC=-pedantic -DBOOST_NO_AUTO_PTR -Wno-ignored-attributes > #PEDANTIC= -DBOOST_NO_AUTO_PTR -Wno-sign-compare -Wno-parentheses > -Wno-maybe-uninitialized > > > | but I'm not sure how to resolve > | > "internal::first_aligned<int(unpacket_traits<DefaultPacketType>::alignment),Derived>(m);" > | which is causing the compilation error. > > That is worse. It seems to rely on 64bit layout. Yet is uses 'int' as > opposed > to 'int64_t' which would hardwire the size. > > Is the 'int' under your control? Can you make that an int64_t? > > I don't have any other suggestions. :-/ > > Dirk > > | I've tried with C++11 and C++14; same result. I've seen some discussion > | elsewhere that this could be related to the -fopenmp flags here: > | https://github.com/kharchenkolab/N2R/blob/master/src/n2/Makefile > | Perhaps there's something here which clashes with RcppEigen on windows? > | > | Any help is appreciated. Here is the CRAN builds: > | https://win-builder.r-project.org/D98h1Y2Rr004/ > | > | Best, Evan > | _______________________________________________ > | 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 > -- > 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
