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?
Thought about it some more. I would expect PPC to be fine. I don’t know about s390; need @vivkong to take a look to answer that.
Great. For reference, this is a two line change that is easy to test if one has doubts:
Sorry for MIA. I’ll give the change a try and report back.
Looks good on s390x. Thanks.
msvcprt works on Windows, libstc++ works on Linux.
Thanks everybody. I’ve merged the change. Please let me know if you see any problems.