Merely building libc++.a shouldn't require a bleeding-edge compiler; but in order to build libc++.a you need to compile src/optional.cpp, which requires being able to parse include/optional (and for some reason to do this in full C++2a mode). Apple Clang 10 (my current Xcode version) doesn't do constexpr destructors (wg21.link/p0784), so it can't build libc++.a for this solitary reason. Let's just fix this one thing.
Details
Details
- Reviewers
ldionne - Group Reviewers
Restricted Project
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Merely building libc++.a shouldn't require a bleeding-edge compiler;
You can and should be using the runtimes build if you don't want to install a recent "system" compiler.
Let's just fix this one thing.
This is a matter of policy. It's easy to add small workarounds, but the sum of all those workarounds is what becomes harmful. We don't test on AppleClang 10 (nor on any Clang that old), so it's not supported. Is there a reason why you can't use a more recent AppleClang?
See https://lists.llvm.org/pipermail/llvm-dev/2021-March/149249.html for our compiler policy. I've been meaning to update the docs to explain that policy for a while now, I'll prioritize that now.