Update to xtensor 20.4

[DavisVaughan]

I'm happy to see this broke Travis. I have been having the same Travis issues but all is well when I compile locally with clang. I think it shows up on g++ only but I may be wrong. I was planning on reporting today but had a few issues reproducing it

[SylvainCorlay]

Yes we are out for the day but neither johan or me can reproduce this locally.

[wolfv]

seems like there might be a missing default construcotr for the buffer adaptor?

[SylvainCorlay]

Actually not! We set it to = default... and both johan and I are not reproducing locally. Also it seems to occur across compilers and platforms.

[wolfv]

Maybe it's because a pointer member is not default constructible (like a reference or something?).

Also couldn't reproduce with gcc9

On Sun 14 Apr 2019 at 23:04, Sylvain Corlay notifications@github.com wrote:

Actually not! We set it to = default... and both johan and I are not reproducing locally. Also it seems to occur across compilers and platforms.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/QuantStack/xtensor-r/pull/110#issuecomment-483058153, or mute the thread https://github.com/notifications/unsubscribe-auth/AA2BPnjW_G4MDoJRA7ncoiev3a28Qz9sks5vg5fugaJpZM4cusA4 .

[DavisVaughan]

Based on what I am seeing, the issue is in the building of Xtensor.R not anything specific to xtensor-r right? And it looks like maybe it has something to do with one of the cpp files in Xtensor.R's src/ directory? I thought that was the case because I am seeing:

Error: package or namespace load failed for ‘xtensor’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/home/travis/miniconda/lib/R/library/xtensor/libs/xtensor.so':
  /home/travis/miniconda/lib/R/library/xtensor/libs/xtensor.so: undefined symbol: _ZNSaISt7complexIdEEC1Ev

which demangles to std::allocator<std::complex<double> >::allocator() being the undefined symbol.

Looking at Xtensor.R, you use complex here: https://github.com/QuantStack/Xtensor.R/blob/dddfcbbd709d19ce60324e7f5fbc256de331b58d/src/test-types.cpp#L30

The #include header of rarray.hpp would also pull in rcontainer.hpp which has <complex> in it so idk why that would fail, but maybe that is it.

[DavisVaughan]

For reference when i was testing this a little while back i was just working with Xtensor.R and got the same error https://travis-ci.org/DavisVaughan/Xtensor.R/jobs/519931021#L1743

[DavisVaughan]

I can confirm that commenting out src/test-types.cpp and the corresponding testthat/test-types.R file results in passing Xtensor.R builds.

However:

• Just adding #include <complex> to the top of src/test-types.cpp does not result in a passing build.
• Adding #include <complex> to xtensor.h also does not result in a passing build (i thought this may help because xtensor.h get's included in the RcppExports.cpp file that compileAttributes() makes.

[SylvainCorlay]

Thanks @DavisVaughan! I really don't know what is going on.

As I was suspecting a mismatch of STL versions used in Rcpp and our extension, I tried building xtensor-r with the GCC compiler that is used to build the Rcpp conda package, and am getting a similar error but with the tests of xtensor-r, and at build time:

https://travis-ci.org/QuantStack/xtensor-r/jobs/521041719

Just opened another PR (#111) to track this other approach.

[DavisVaughan]

Maybe it might be smart to also try to make sure that things are still passing with the last known build that worked fine. Like, go restart a travis build that included std::complex pieces but uses an older version of xtensor that we know passes. If that still passes, we have isolated the problem to an xtensor change. (as opposed to some conda change or something)

[SylvainCorlay]

This appears to be a compiler bug. @JohanMabille found a workaround for xtensor-r that I will push shortly.

[DavisVaughan]

All i have to say is, wow.