You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In conda-forge we're building under some different constraints than for CRAN, which leads us to use different compilers etc.
As it turns out a change in r-cpp11 v0.4.4 ended up breaking the R-bindings for arrow, only that we weren't able to root-cause the issue at the time, and so we haven't had windows builds for r-arrow since about 8 month.
After some digging together with the arrow folks, it seems to be a combination of two things
the fact that cpp11::writable::r_vector<double>::iterator has no copy assignment operator (implicitly deleted by the compiler)
It seems that the STL stumbles over this combination in its implementation of std::transform:
In file included from altrep.cpp:18:
In file included from .\./arrow_types.h:22:
In file included from .\.\./arrow_cpp11.h:20:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\memory:14:
In file included from C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\xmemory:15:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\xutility:1408:13: error: object of type 'cpp11::writable::r_vector<double>::iterator' cannot be assigned because its copy assignment operator is implicitly deleted
1408 | _It = _STD forward<_UIter>(_UIt);
| ^
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.40.33807\include\algorithm:3556:10: note: in instantiation of function template specialization 'std::_Seek_wrapped<cpp11::writable::r_vector<double>::iterator, cpp11::writable::r_vector<double>::iterator &>' requested here
3556 | _STD _Seek_wrapped(_Dest, _UDest);
| ^
D:/bld/r-arrow_1721706669778/_h_env/lib/R/library/cpp11/include\cpp11/doubles.hpp:149:10: note: in instantiation of function template specialization 'std::transform<cpp11::r_vector<int>::const_iterator, cpp11::writable::r_vector<double>::iterator, (lambda at D:\bld\r-arrow_1721706669778\_h_env\lib\R\library\cpp11\include\cpp11\doubles.hpp:149:55)>' requested here
149 | std::transform(xn.begin(), xn.end(), ret.begin(), [](int value) {
| ^
D:/bld/r-arrow_1721706669778/_h_env/lib/R/library/cpp11/include\cpp11/r_vector.hpp:263:21: note: copy assignment operator of 'iterator' is implicitly deleted because field 'data_' is of reference type 'const r_vector<double> &'
263 | const r_vector& data_;
| ^
whereas libc++ and libstdc++ don't?
I'm not 100% certain that this is the right analysis, but at least I've checked that our windows builds (despite all the infra updates, new R versions & new compilers) builds with 0.4.3, so it would be great if this could somehow be fixed (as indefinitely staying on an old version is bound to lead to other problems).
The text was updated successfully, but these errors were encountered:
Thanks for digging in. I'm planning a patch release in the next 2-3 weeks, I'll try and get a patch for this in too. I'll probably need you or someone else to verify the PR works once I make it!
In conda-forge we're building under some different constraints than for CRAN, which leads us to use different compilers etc.
As it turns out a change in r-cpp11 v0.4.4 ended up breaking the R-bindings for arrow, only that we weren't able to root-cause the issue at the time, and so we haven't had windows builds for
r-arrow
since about 8 month.After some digging together with the arrow folks, it seems to be a combination of two things
std::transform
in 28538e5cpp11::writable::r_vector<double>::iterator
has no copy assignment operator (implicitly deleted by the compiler)It seems that the STL stumbles over this combination in its implementation of
std::transform
:whereas libc++ and libstdc++ don't?
I'm not 100% certain that this is the right analysis, but at least I've checked that our windows builds (despite all the infra updates, new R versions & new compilers) builds with
0.4.3
, so it would be great if this could somehow be fixed (as indefinitely staying on an old version is bound to lead to other problems).The text was updated successfully, but these errors were encountered: