Date: Mon, 03 Oct 2022 03:54:07 +0000 From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 266748] '#include <memory_resource>' isn't available despite it being required by c++17 Message-ID: <bug-266748-99-SnKFSbskfF@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-266748-99@https.bugs.freebsd.org/bugzilla/> References: <bug-266748-99@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266748 --- Comment #6 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (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=3Dlibc++ and -stdlib=3Dlibstdc++ 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). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266748-99-SnKFSbskfF>