memory_resource is installed as an experimental header: /usr/include/c++/v1/experimental/memory_resource Only '#include <experimental/memory_resource>' works, but '#include <memory_resource>' doesn't work. ==References== [1] https://en.cppreference.com/w/cpp/memory/memory_resource
Additionally, std::pmr::monotonic_buffer_resource isn't defined in the current implementation. ==References== [1] https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource
If you look at https://en.cppreference.com/w/cpp/compiler_support/17 you will see "Polymorphic memory resources" documented as not supported by "Clang libc++". That in turn suggests that the experimental support is insufficient So: Not FreeBSD's problem (yet).
science/qmcpack requires memory_resource. I will have to switch it to GCC to work around this problem.
(In reply to Yuri Victorovich from comment #3) The various: https://en.cppreference.com/w/cpp/compiler_support/* are good thing to look at when the default environment seems to have insufficient features. The pages also cover "GCC libstdc++" in addition to "Clang libc++", as well as core language features for GCC and for Clang. For officially released vintages of the C++ standard, GCC and GCC libstdc++ tend to have more complete coverage in some version than LLVM clang++ and its libc++ does. For either LLVM or GCC, the vintage may at times need to be newer than the FreeBSD ports available or the system-clang++ version in FreeBSD's main [so: in 14 currently]. libc++ does not have port-specific versions, however. The LLVM ports use the system's libc++ . This can also lead to GCC libstdc++ having better language coverage for more modern C++ vintages.
Unfortunately science/qmcpack tests fail when it is built with GCC. So this issue is a show-stopper for science/qmcpack.
(In reply to Yuri Victorovich from comment #5) I see that 3.14.0 was building okay, so a new 3.15.0 issue? Looking I found: qmcpack/CMake/Testlibstdc++.cmake which suggests that they require libstdc++ : # Test that if a C++ compiler is compatiable with the libstdc++ in use But there are also: ClangCompilers.cmake GNUCompilers.cmake IBMCompilers.cmake IntelCompilers.cmake NVHPCCompilers.cmake So they seem to allow a variety of compilers, just when compatibile with the libstdc++ in use. I'm not aware of anyone having set up a FreeBSD clang++ context (system or ports) that allows for clang++ use with a libstdc++ . As I understand, LLVM does allow for providing -stdlib=libc++ and -stdlib=libstdc++ on the same system, using the same compiler. So I expect setting this up is a FreeBSD ports sort of activity, not an upstream activity. I would not expect the system FreeBSD to add libstdc++ (licensing issues, other issues).
(In reply to Mark Millard from comment #6) Hmm. CMake/TestCxx17Library.cmake has this for when it rejects the C++17 library support: elseif(CMAKE_CXX_COMPILER_ID MATCHES "Clang") message( "Compiler detected is clang++.\n If not using libcxx, ensure a GCC toolchain version equal or greater " "than 9.0 gets picked up. Check with 'clang++ -v'. Or use the --gcc-toolchain compiler option " "(added to CMAKE_CXX_FLAGS) to point to a newer GCC installation." ) --gcc-toolchain is not something I was aware of. Its description from: https://releases.llvm.org/15.0.0/tools/clang/docs/ClangCommandLineReference.html is: --gcc-toolchain=<arg> Search for GCC installation in the specified directory on targets which commonly use GCC. The directory usually contains ‘lib{,32,64}/gcc{,-cross}/$triple’ and ‘include’. If specified, sysroot is skipped for GCC detection. Note: executables (e.g. ld) used by the compiler are not overridden by the selected GCC installation I wonder if getting that set up is an option via ports. Correction to earlier note: The "If not using libcxx" suggests that libstdc++ might not be required for clang if/when libc++ is sufficient --but the above indicates that libstdc++ would still be a possibility. But, I also seem to remember that there is a C++ language change that creates a ABI change requirement that is pending for FreeBSD. Such could create problems until things match up for clang++ vs. g++ .