Right now, the build-script forces the use of LLVM's libc++ via CMake and the LLVM_ENABLE_LIBCXX build option. I'd like us to consider removing this hard coding and trust that any C++ standard library will work. At the moment, there is evidence that this change will work just fine on various platforms, be they macOS, Linux, or even Windows.
(I also personally suspect that this hard coding dates back to when macOS had both the GNU and LLVM C++ standard libraries installed, but perhaps this perspective doesn't matter.)
Can anybody think of any reason why the build script should continue to force LLVM's libc++ to the the preferred C++ standard library?
@vivkong, @dgrove-oss, do you or anyone else from IBM foresee any problems with this on PPC or s390x (or even a Linux config that's not the one on the bots)?
I'd wonder about platforms where clang isn't the default C++ compiler. Will clang be smart enough to not try to link C++ code it generated with a C++ stdlib compiled by another compiler? It at least used to be the case that the C++ object model used by xlC was not compatible with that used by other C++ compilers.
This change is only about what C++ standard library the compiler uses for its own use, not clients of the compiler. What we need to know is whether xlC's default C++ standard library is good enough for the needs of LLVM derived projects. If xlC's default C++ standard library works for LLVM+clang, then it'll probably work just fine for LLVM+clang+swift+lldb. Does this change your concerns at all?