3.12.0 release is broken: error: no matching member function for call to 'reextent'

[yurivict]

In file included from /disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOASCII.cc:16:
In file included from /disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IO.h:20:
In file included from /disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOBase.h:26:
In file included from /disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOVar.h:20:
In file included from /disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOVarASCII.h:20:
In file included from /disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOVarBase.h:22:
/disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/Blitz.h:75:54: error: no matching member function for call to 'reextent'
        void resizeAndPreserve(sizes_type sizes){base_type::reextent(sizes);}
                                                 ~~~~~~~~~~~^~~~~~~~
/disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOVarASCII.h:352:14: note: in instantiation of member function 'Array<bool, 4, boost::multi::array<bool, 4>>::resizeAndPreserve' requested here
  ArrayValue.resizeAndPreserve(dims);
             ^
/disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOVarASCII.h:173:3: note: in instantiation of member function 'IO::IOVarASCII<bool, 4>::Resize' requested here
  IOVarASCII(std::string name) { Name = name; }
  ^
/disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/src/QMCTools/ppconvert/src/common/IOASCII.cc:621:35: note: in instantiation of member function 'IO::IOVarASCII<bool, 4>::IOVarASCII' requested here
        IOVarASCII<bool,4> *newVar = new IOVarASCII<bool,4>(name);
                                         ^
/disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/external_codes/boost_multi/multi/array.hpp:910:7: note: candidate function not viable: no known conversion from 'Array<bool, 4, boost::multi::array<bool, 4>>::sizes_type' (aka 'std::tuple<long, long, long, long>') to 'const typename array<bool, 4>::extensions_type' (aka 'const extensions_t<4L>') for 1st argument
        auto reextent(typename array::extensions_type const& x) -> array& {
             ^
/disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/external_codes/boost_multi/multi/array.hpp:941:7: note: candidate function not viable: requires 2 arguments, but 1 was provided
        auto reextent(typename array::extensions_type const& x, typename array::element const& e) -> array& {
             ^

clang-13
OS: FreeBSD 13

[prckent]

Sorry about this Yuri! We have CI and nightlies with clang so i am puzzled how this got through, but clearly it did get through. Since the last release we have made building a previously optional utility (ppconvert) the default, and this is where the problem trips. Can you please add your cmake line and output?

I am traveling and so can't test the following, but perhaps try commenting out the ppconvert line on line 57 of https://github.com/QMCPACK/qmcpack/blob/develop/src/QMCTools/CMakeLists.txt to disable ppconvert. This would completely localize the error.

Interestingly clang13 is OK on develop, e.g. test output https://cdash.qmcpack.org/CDash/testDetails.php?test=13109421&build=278135, cmake output: https://cdash.qmcpack.org/CDash/viewConfigure.php?buildid=278134 ).

[yurivict]

No problem!

Here is the full build log.

[yurivict]

Both clang 12 and 13 break the same way.

---

There is no particular urgency for me. I encountered this problem while trying to update the FreeBSD port science/qmcpack.
Please take your time.

Thank you!
Yuri

[prckent]

@correaa Since this traces to multi, and before we do any deeper investigation, can you guesstimate if there are any #ifdef I_AM_LINUX or #ifdef I_AM_BSD in multi that could cause this difference? Since the same compiler versions appear to work on Linux, presumably there is either a difference in multi or some contamination from system includes that is causing this issue.

[correaa]

mmm. No, I don't make a conditional compilation depending on Linux vs BSD or anything like that. My first guess is that there is an accidental difference in the clang compilers in BSD. or in their corresponding STLs?

After all, I noticed lately that CMake can distinguish between clang and clang-apple, no?

maybe that's it, although the compiler is the same one could be compiling against libstd and the other against libc++.

[correaa]

Sorry, I assumed this was an Apple computer. Is it? Is there a CI for Apple/BSD?

[yurivict]

Sorry, I assumed this was an Apple computer. Is it? Is there a CI for Apple/BSD?

No, this is FreeBSD.

[williamfgc]

@correaa there is a CI job for GitHub Actions Apple runners based on Accelerate.

I'll try a FreeBSD VM to try to reproduce. Looks like there is an issue with unpacking (or packing) tuple arguments on that particular platform configuration:

/disk-samsung/freebsd-ports/science/qmcpack/work/qmcpack-3.12.0/external_codes/boost_multi/multi/array.hpp:910:7: note: candidate function not viable: no known conversion from 'Array<bool, 4, boost::multi::array<bool, 4>>::sizes_type' (aka 'std::tuple<long, long, long, long>') to 'const typename array<bool, 4>::extensions_type' (aka 'const extensions_t<4L>') for 1st argument
        auto reextent(typename array::extensions_type const& x) -> array& {

[correaa]

Thank you, yes. It is also likely to be fixed in the last (tagged) version of Multi: https://gitlab.com/correaa/boost-multi/-/releases/v0.78 if you decide to update.

BTW, this version of Multi has a more CMake-friendly directory structure (basically the include files all or under repo/include/multi/*). It also has a proper CMakeLists.txt (if I got it right).

[prckent]

Thanks @williamfgc . The puzzle to me is why tuples cause the problem on FreeBSD and no-where else that we know of...

If bumping the version of multi proves to be the solution, we could just push out a new release. The recently added QE7 support is a sufficient new capability that it is worth releasing.

[prckent]

Note #3703 . Newer multi is needed to fix some Intel compilations.

[williamfgc]

Thanks @williamfgc . The puzzle to me is why tuples cause the problem on FreeBSD and no-where else that we know of...

@prckent yes, that's what got me interested as FreeBSD ditched gcc in favor of being a "pure" llvm/clang system by default.

From @correaa (thanks!):

maybe that's it, although the compiler is the same one could be compiling against libstd and the other against libc++.

The above, I'm able to reproduce with libc++10 on Ubuntu 20.04 (and on a FreeBSD 13 VM as well) independently of clang compiler version:

sudo apt install libc++-dev libc++abi-dev
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} -stdlib=libc++ -lc++abi" -DQMC_MPI=0 -DCMAKE_BUILD_TYPE=Release ..

Now, our CI doesn't cover usage of libc++ (clang still links to GNU libstdc++), perhaps it would justify adding it as libc++ is more adopted? There is another bunch of errors when building. Thanks @yurivict for reporting this.

Now moving to understand the error.

[williamfgc]

FYI, this libc++ issue might be related. There are tuple API changes in libc++ 13 release notes.

[correaa]

I understand is that BSD would be willing to jump to llvm as much as they can because GNU and BSD licenses are historically incompatible.

I am also bad at covering against libc++ because all my CI systems are linux. Is there a BSD system available in DockerHub that you can recommend, e.g. something that can be used as Debian? I am not familiar with BSD.

Sorry, I just realized that I can test libc++ in linux as well from the previous message.

[yurivict]

Cirrus CI supports FreeBSD.

[williamfgc]

GitHub Actions has a FreeBSD VM action that runs on macOS hosts.

[correaa]

Thank you for your help.

Any idea why Boost.Test would fail to link when switching to libc++, https://gitlab.com/correaa/boost-multi/-/jobs/1945458031#L700

[PDoakORNL]

I think there are likely to be other issues with libc++ and QMCPACK. My understanding was we don't officially support it. I've never had success compiling with our offload offload or CUDA using libc++.

[PDoakORNL]

All my clang builds use the gnu stdlibc++

[williamfgc]

@correaa looks like ABI incompatibility on your boost libraries, I guess built with libstdc++ and one of the reasons it's hard to mix with libc++ as @PDoakORNL pointed out. Having FreeBSD CI somehow would isolate LLVM from any GNU noise (including dependencies), but mixing toolchains can bring ABI problems on Linux (I was probably just lucky with QMCPACK actually, you're all doing a great job writing portable C++). So far, I only found this problem and a missing #include <array> header in HEGGrid.h.